Page 2 of 3

Posted: Sat May 16, 2009 9:06 am
by Zefz
The thing that makes Egoboo coding so very hard, is as birdsey pointed out the instability (and not necessarily it's understandability). Egoboo is like a house of cards, where you try to modify one of the cards on the bottom and the whole thing comes falling down (well, not as extreme as that, but many other things you are unaware of is also affected by your seemingly harmless change).

Posted: Sat May 16, 2009 8:47 pm
by Poop Loops
bgbirdsey wrote:
I might even be able to fix the physics bugs. Smile


Trust me, that is no piece of cake. I have a ph.d. in physics and have an interest in computational mathematics. The problem is not with big structure of the code and it's inherent instability to change. I've "fixed" the physics system many times, but it messes with some other game mechanic that is tuned to the current broken system...

[quite]So that you guys can keep developing and not spend your time looking for bugs, or at least fixing crucial bugs and not worrying about cosmetic ones.


We definitely need bug testers. If you even could download the code and try to track down bugs with a debugger that would be awesome. Trying to track down bugs is a tremendous time sink.[/quote]

Oh wow, what field did you do your Ph.D. in? I'm still not sure what I'll be specializing in, but I hear that's common.

Anyway, yeah, I'll sit down and take a better look at the code tomorrow to figure out how stuff works, and I can start with debugging the code. I've only had to debug small programs before, though, which involved stepping through each command to see where the program does something I wasn't expecting. Is there a better way to do it in this case? I've used gdb when I was getting a segfault from SDL_mixer, but that was because the program was crashing. And of course, if I try to pick up a spell book and it won't let me, it's kind of obvious that I'd look in the code for picking up objects and the code for spell books. But is there anything that would help me narrow it down or am I stuck doing it the hard way, searching line by line to see where something is wrong?

Zefz wrote:The thing that makes Egoboo coding so very hard, is as birdsey pointed out the instability (and not necessarily it's understandability). Egoboo is like a house of cards, where you try to modify one of the cards on the bottom and the whole thing comes falling down (well, not as extreme as that, but many other things you are unaware of is also affected by your seemingly harmless change).


Well that's what you get for using C. :P Making it all object-oriented would make the thing a lot easier, except that overhauling all of that would be a lot easier said than done, huh? :(

So anyway, any tips on where to start in order to figure out the structure of the code and how things work? I've been going through all of the *.c files, but I've yet to go over any scripts.

Posted: Sat May 16, 2009 8:57 pm
by Zefz
About your SDL_mixer segfaulting: Are you sure you use the latest revision from the SDL_mixer repository and not the downloadable package that they offer.

Posted: Sat May 16, 2009 9:15 pm
by Poop Loops
Oh, I reinstalled Ubuntu and the problem went away. I upgraded from 8.04 to 9.04. I guess something was just conflicting. Yeah, I had the latest SDL_mixer compiled from source, I believe, and it was still messing up. So I never did figure out the problem.

Posted: Sat May 16, 2009 9:28 pm
by penguinflyer5234

Posted: Sat May 16, 2009 9:38 pm
by bgbirdsey
Both Zefz and I are on win32 platforms and use MS Visual C, which has a pretty excellent symbolic debugger that allows you to do all the normal things, as well as things like make code changes while the code is running. :)

I have never been able to get gdb to work, so you're on your own there!

You will see that the project includes a code::blocks project file. AFAIK code::blocks is pretty good, as far as IDEs for linux.

The only real benefit to C++ over C is the automatic initialization, strong type checking, and operator/function overriding. All of those things are hidden in the compiler. Just about everything else can be ported directly to C.

In out particular case, we really *need* the strong type checking and the automatic initialization. It is the lack of these things that are causing a lot of the problems with re-arranging the order of function calls. The other thing is that there was little thought to code abstraction / code factoring, so there is all this repeated code all over the place and if you make a mod, you have to remember to track down every similar code fragment...

------------------

I do have a C++ version of the 2.22 code. If we had made the decision to go that route years ago, a lot of the current problems would already be solved.

One problem with oo code, especially when you introduce inheritance, is that you can easily obfuscate the "main loop" of the program. This makes debugging quite hard and makes the learning curve quite steep.

However, if you are disciplined, you can do some amazing things! ;)

Posted: Sat May 16, 2009 9:55 pm
by Zefz
bgbirdsey wrote:Both Zefz and I are on win32 platforms


I'm on a win64 platform ;) And now I run dual boot linux64 as well now, so theoretically I can try debugging Egoboo on Linux as well as Windows. :roll:

Posted: Sat May 16, 2009 9:58 pm
by bgbirdsey
that's cool. I bought an entirely new computer to debug on linux...

Actually it was for playtesting networking... umm... nothing to see here... move along...

Posted: Sat May 16, 2009 10:39 pm
by penguinflyer5234
bgbirdsey wrote:I have never been able to get gdb to work, so you're on your own there!


Compile with the option -g to gcc

Posted: Sat May 16, 2009 10:55 pm
by bgbirdsey
I realize that, but there is a problem initiating gdb from code::blocks, and it did not really want to give me the info I wanted from the command line... Also, I was not willing to spend the time to dig through the manual... I'm lazy ;)

Posted: Sat May 16, 2009 11:29 pm
by Poop Loops
I am closer to fixing my exporting error. It will export when I exit a module + exit the game right afterwards. When I come back and enter a module, I have all my stuff still. I found out why, too.

In game.c, memory_cleanUp calls quit_game which calls quit_module which calls export_all_local_players. Obviously memory clean up only happens when you are exiting the game. This means that exiting a module doesn't export anything, but still keeps all variables in memory, and exiting the game is what writes it.

Following export_all_local_players leads me to export_all_players, which is called by game_update_imports. This is called by link_follow_module in link.c, which is defined as part of script FFOLLOWLINK in script.c

From here I am lost, because doing a grep on FOLLOWLINK doesn't return anything except in the /Obsolete/ folder and in script_compile.h, which also just initializes the scripts.

So instead I went back to the C code and found game_quit_module, which calls release_module and close_session. None of these export characters. close_session is just a network function which isn't used now and release_module just frees up memory. I put export_all_local_players in game_quit_module and it still isn't working, so I put game_input_module instead, and then stuff got messed up, as in my items wouldn't export correctly.

Posted: Sat May 16, 2009 11:46 pm
by bgbirdsey
quit_module is called from the module exiting menu, or it is supposed to be being called, maybe it should be game_quit_module, though...

game_quit_module is the function that the main loop is supposed to call to fully quit a module. The code was abstracted from the main loop and exposed to the module linking code. Now, the module linking code could actually close a module and start a new one in exactly the same way that the main loop does. Also, there are only two functions to maintain.

You may be onto something, though!

Posted: Sat May 16, 2009 11:51 pm
by Poop Loops
I guess I'm closer, since I went from not exporting anything to exporting everything, except items get messed up in the process. :)

I've basically been trying to find where modules get started and ended, so I can see what happens. I found the end part, but I have to get more familiar with how modules get started now.

Posted: Sun May 17, 2009 2:15 pm
by penguinflyer5234
It seems that Egoboo steals your mouse even when [GRAB_MOUSE] is set to FALSE.
And it doesn't hide it either.

^ In the menus only, it seems.

Also seems impossible to light torches, rendering the Healer Starter unfinishable

Posted: Sun May 17, 2009 3:36 pm
by bgbirdsey
ARGH! Thanks for reminding me. I need to fix this next!

--------------------

Fixed