SDL graphics help???

[TJA]

I'm new to graphics programming so I thought I would try implementing some graphics for my phoenix arcade emulator before moving on anymore on my GameBoy emulator, did my chip8 emulator in SDL and decided to use it again, all other code on my phoenix emulator works fine, its just implementing graphics that I'm having trouble with, I'm not 100% about the code I'm using to implement the palettes but it still should be displaying something the program starts up a display window is created then it hangs. I'm not sure how to find the problem, so I though I would post my code so someone might give me a hand.
My graphics code is based on the code found in JABAWAPE v0.8 emu which uses allegro.

I appologise for the code to some parts are a little messy and theres a bit of old code hanging around that I will remove/modify as soon as I get the graphics going.

Any help/suggestion appreciated

Cheers, TJA.

Code updated with fix ( graphics still not working correctlt)

 

[bcrew1375]

Are you periodically processing SDL's events? It will hang with a white window if you don't deal with them.

Something like: SDLPumpEvents()

 

[TJA]

Thanks, bcrew its always something simple it doesn't lock up anymore, now I just have to figure out why nothing is being displayed.

Cheers, TJA

 

[TJA]

I have some display now, It seems the graphics is being drawn to the correct locations I'm just having trouble with the palettes and combining the background and forground image.

I have uploaded my latest code incase someone can help me.

Cheers TJA.

 

[TJA]

Seems its just my lack of graphics prgramming knowledge thats slowing me down, but I'm learning and that was the purpose of the emu anyways I almost have a fully working phoenix emulator just a couple more things to fix such as fixing whatever is causing some of the display to be left out such as you can see on the phoenix logo on the screenshot bellow. Then to add some input support which shouldn't take long. ( Then maybe clean up my messy code )

TJA.

 

[TJA]

I'm slowly getting there I fixed a problem with transparancy in the forground, and also found why the background was not being displayed properly ( forgot to change a couple of instructions to real z80 instructions instead of gameboy instructions ), I'm thinking the cpu is also what is casing display issues with the logo, and also why emulation stops when this screen is reached.
I hate this part it gonna be a pain finding this bug.

TJA.

 

[ShizZy]

Looks nice, keep it up.

 

[GCFreak]

I agree, keep it up TJA.

 

[TJA]

Well I've been working on fixing the bugs in my cpu and the result is that the game shows less graphics than before, in fact its been a lot of work just getting the game running to the same point it was freezing at before I fixed these errors. My CALL opcodes are now correct and so are my return opcodes but it is still pulling addresses off the stack and jumping to opcodes that it shouldn't. I'm really not sure how to track down whats wrong. I have a simple debugger the problem is knowing where to look, I have looked over all my opcodes indevidually and they seem correct but clearlly something is wrong.

TJA.

 

[bcrew1375]

Are you sure you are using the correct endianness? Are you sure you are properly pushing/popping the stack(Pushing and popping the bytes on and off in the correct order)? Are you pushing the address of the next instruction onto the stack, instead of pushing the current address? Just trying to get some ideas here.

 

[TJA]

My push and pop opcodes are working correctly as fare as I can tell, and yes I though maybe it could be an endianness thing but I'm 99% sure its not, I think its something to do the addresses being pushed onto the stack by opcodes such as C5 which makes the bugs hard to track down as there are a number of fators that contribute to the value of final address being pushed. Opcode C9 is poping opcode FF from stack but the game does not use this ocode ( at least not at this point )
Anyway as far as the graphics goes it is now displaying all that it was before. I forgot to change something back after I was playing around and some carryflags were not being set correctly. Now it gets to the same point as before then it displays some scrammbled graphics. Also the logo (top and bottom missing ) and position of the phoenix bird are still wrong. So in summary I fixed around 15 or so opcodes and have seen no real change theres something I'm missing but just cant find.

TJA.

 

[ShizZy]

I was playing around and some carryflags were not being set correctly.

You've probably heard this a million times but the big things that cause issues in a lot of Z80 emulators are the C and Z flags (N and H don't really matter at this stage), and your rotates and shifts. Rotates and shifts are very easy to make little mistakes with and throw a bunch of stuff off.

I've made multiple debuggers, but I can never seem to use them efficiently. What works best for me is to just go through each line of code with a fine needle.

 

[TJA]

Success finally, after reading your post I went back and checked my shifts, and lucky I did when getting the value from bit 7 and putting it in the carry flag I had been using reg.A>>8 which would have been setting carry to 0, anyway this will have saved me trouble in the future, but again this did not solve my graphics issues. As for rotates I have not implemented them yet as the 8080 does not use them. So I decided to check every opcode the game used in the order it used them. I set my debugger to stop at every new opcode and then I went and check my code for that opcode I was about to give up then there It was one stupid greater than sign that should be a less than, in my SBC macro for setting the carry_flag. Now the graphics is spot on.
Finally I can move on to my gameboy emu, I just couldn't start it knowing there was a bug sit in my cpu.

Thanks for suggestions guys.

Cheers, TJA.

Oh and by they way in the Z80, H, and S do matter as it has opcodes that use them to decide whether to jump or return just like the gameboy does with C and Z.

 

[ShizZy]

Err.. I'm referring to the GB cpu then, if that's different. H and N are BCD flags, and only used by the DAA instruction for calculating scores and things. I've never seen them break a game.

Z and C are the jump flags.

Anyways, glad the shifts suggestion helped. They were an issue in my gb emu for a while.

 

[TJA]

Yeah your right the instructions that use H and N, other than DAA do not exist in the gameboy cpu I dont think they are used very often possibly why the were removed.

Cheers, TJA.