Mini Motors

[Johan Kårlin]

Regarding progression of the game, I'm starting to fear that I'll have to start over in assembly.
I've almost reached the limit for how much memory the C compiler can use, and I have bugs and memory corruption everywhere, which may be because of the C compiler and the memory running out or overwriting different structs etc.

My game is about 34 Kb and that is only code so you might run out of memory. On the other hand I use a lot of macros that waste memory by adding the same code logic over and over again.

Edit: Also, I'd really like to have the graphical skills to create 8-bit pixel art, like what you have in your game : )

Sorry to say, I also lack graphical skills. Mopspear has helped me with the graphics. The font is ripped from the C64 original.

[Johan Kårlin]

One thing I really don't understand is how I can end up with only one corrupted car sprite, when all cars are the same sprite only with different palette offsets. I would think that in that case all car sprites should be corrupted?

If only one car is affected, the actual sprite image data is intact. It must be the address pointers (the first two attributes) for the actual sprite that are changed by some reason. Which index does the affected sprite have? Is it 0? The mouse pointer is sprite 0 and you might have an interference with the system?

[Dacobi]

If only one car is affected, the actual sprite image data is intact. It must be the address pointers (the first two attributes) for the actual sprite that are changed by some reason.

I already started to suspect this. I've made some changes to how I store and write sprite properties to VERA, but it didn't help, so now I'm thinking it must be the code I use to set the sprite offset from the car angle.

Which index does the affected sprite have? Is it 0? The mouse pointer is sprite 0 and you might have an interference with the system?

Ahhh, now it makes sense. I've been wondering for quite some time why my first sprite was sprite index 1 : )
I originally found some C code for rendering sprites on VERA and never knew why I started with sprite index 1.

[Johan Kårlin]

I already started to suspect this. I've made some changes to how I store and write sprite properties to VERA, but it didn't help, so now I'm thinking it must be the code I use to set the sprite offset from the car angle.

It certainly sounds like a main suspect. If you don't find the bug there, the best you can do is to continue to check all code that writes to VRAM.

[Dacobi]

I've been able to demonstrate that the sprite offset for the cars both ends up larger than the number of sprites and below zero, but I haven't been able to find the cause.

It might be the result of some completely unrelated memory corruption.
The only thing that seems to be a trigger is when the game is struggling, where all 4 players are alive and some frames take longer than 1 frame time to compute, but other than that I can't seem to figure it out.

Edit: I've simplified my code for setting the car sprite offset from the car angle and if I start a race with 2 players and 2 bots and immediately let one player die it's a lot more stable, with only rare bugs. I still end up with invalid sprite offset sometimes which I do not understand.


One thing I've been considering is this C macro:

Code: Select all

	#define SPRITE_BLOCKHI(addr) (addr >> 13)

This is for setting the Hi address value of a sprite register and I'm not sure what effect the statement will have when "addr" is a #define larger than 16bits with a 16bit int offset added to it?
Edit: The thing that concerns me is whether bit 16 is lost in the process and if that would have adverse effects?
Edit2: I've tried hardcoding the values for Hi and Lo and then just adding the shiftet sprite offset and it doesn't seem to make a difference.

Regarding the problem with running the game with all 4 players alive, the culprit seems to be my car collision code. The 6502 simply can't handle this code when all 4 players are in a group close together.

[Dacobi]

I just uploaded a SD test image where I've decreased the distance between cars for when I solve for collision and added checks for the sprite offset.

It's now a lot more stable with 4 cars, but I still experience some massive weirdness. Now the primary problem is that the car/sprite position for player 4 is all over the place, but I no longer see corrupted sprites as much as sprites that "flicker".

With 3 live players is actually quite stable.

[Dacobi]

I just uploaded an SD image where I've changed the game to only start with 3 players.
This has made the game a lot more stable and is now playable with only a few bugs now and then.

I simply don't understand how frames taking longer than one VSYNC to compute can cause this kind of total and random memory corruption?

Another theory I had was if the C compiler maybe ended up corrupting or overflowing the stack/heap when 4 players were alive?
But I know next to nothing regarding how stack/heap etc works with a C compiler and a 6502 CPU.

Instead of the 4th player in the menu there's now a setting for "AI LEVEL".
It's a simple way to add a difficulty level. It just adds an offset to AI max speed, with 3 being neutral.

If anyone wants to play around with the game there's a shortcut, "CTRL + Q" to quit the current race for cases where you don't want to wait for the race to finish.

PCM audio is also back and the only bug I've found is a small pop/click when the game first starts the menu, but it doesn't seem to happen later, when PCM audio is played.

[Ed Minchau]

I simply don't understand how frames taking longer than one VSYNC to compute can cause this kind of total and random memory corruption?

Another theory I had was if the C compiler maybe ended up corrupting or overflowing the stack/heap when 4 players were alive?

Do you have a custom IRQ? Does it access either channel on VERA?

[Dacobi]

Do you have a custom IRQ? Does it access either channel on VERA?

I do have a custom IRQ handler which during VBLANK updates tilemaps scroll and car sprite position and offset + PSG registers and sets a flag in my C code during sprite collision interrupt.

I understand that writing these values to VERA while I'm writing to them in my main loop will cause some problems, but how would it end up corrupting normal RAM and not just VRAM?

[Dacobi]

I just uploaded an SD image, where the game is a lot more stable.

I've identified different places in the code where there was a risk that both my main loop and VBLANK interrupt could write to VERA data0 at the same time. Now all VERA access has been moved to the VBLANK interrupt.

There's now also a "Laps Counter" during the race and the waypoints have been tweaked for a more stable calculation of the leading player.