0.0.3a Testing

[Robert]

Stressed? Perhaps you're right. I'll give it a rest for while. cya

[NukeFall]

Rest is a good thing.

 

Well since it is open source like Two9A said im gonna try my luck at making a confid option for it fully intergrated not an independant program >>.

Edited April 4, 2005 by NukeFall

[Khaki]

Hi,

 

I've tried compiling the latest CVS version of DSEmu with MS Visual Studio.NET and it complains about a missing config.h file referenced in defs.h. Any tips?

 

 

Thanks

[Khaki]

Ignore that last post, just saw it mentioned in the Makefile. I'm having great fun converting it into a visual studio project.

[NukeFall]

Yea ive had problems using cygwin to compile it cause of config.h but right now im just trying to find out where it handels all the code for the child windows i know where the debugger code is its in its own source file. Im trying to figure out what links that to the main program.

[Khaki]

The *.c files look like they're a mix of formats too, playing havoc with the visual studio editor. ds.c is in UNIX format while mmu.c is in DOS format. Meaning that the line numbers the debugger gives don't match.

 

What child windows do you mean?

[NukeFall]

Child Windows like Debugger and Pallete. Ive gotten pretty far to the point where it creats the windwos and then what toggles then showed or unshowed. I also found each windows proc. I still dont know whats connecting them all though.

[Khaki]

Child Windows like Debugger and Pallete. Ive gotten pretty far to the point where it creats the windwos and then what toggles then showed or unshowed. I also found each windows proc. I still dont know whats connecting them all though.

<{POST_SNAPBACK}>

 

dbgOut in dbgout.c draws the fixed-width characters on the buf argument it is passed. This drawing buffer is linked to the child windows with membuf being attached to the memory debug window, palbuf to the pallette, etc. This is done with the SetDIBitsToDevice call in glds.c I believe.

[NukeFall]

Well from what i can gather all the windows procs and stuff are in glds.c and in glgba.c ill look into that call and see what i find. If that doesnt work ill trace it back from main.c wince thats the main winmain function.

[Two9A]

This drawing buffer is linked to the child windows with membuf being attached to the memory debug window, palbuf to the pallette, etc. This is done with the SetDIBitsToDevice call in glds.c I believe.

Someone understands my code? This isn't right.

 

Well, work backwards from the child window. Take the debugger window. It has its buffer blitted in emuRefresh (one of a few places). Where does the buffer get filled? ARM7status, which has a reference to dbuf. Where does dbuf get passed into the ARM core? emuInit, with ARM7init after it's been allocated. It all ties together.

 

If that made sense, you're a better man than me.

[NukeFall]

Well yea i see emuInit. I think im just not gonna do it the way you did it. I think im just gonna derive everything from win.c in the proc since im so lazy. It shouldnt slow down the emulator at all considering the code would only run when you open the window.