SpritesMind.Net

Sik wrote: Mon Aug 27, 2018 12:58 pm Erm...

Code: Select all

/**
 *  \typedef vu16
 *      volatile 16 bits unsigned integer.
 */
typedef volatile u16 vu16;

Though wait, does volatile actually work in typedef or is it meant to be ignored?

Ah, that's what V in VU16 stands for...
Will at least try it out to see.

Yeah, it's fine then. That reminds me is equally important the code to work and to be easy legible.

mix256 I think you should put the full code where you think there is the error. Also, is there any other location were you update colors?

The situation you are describing is very unusual, also SGDK code is simple and alright to my eyes.

mix256 wrote: Sat Aug 25, 2018 11:56 am "I'll handle the CRAM dots later", I said to myself. Now "later" is here, and I don't know what to do about it.
This should be ok, right?

Code: Select all

VDP_waitVSync();
colorCyclePressStart(colorCycleTimer++);

All that other function do is a few VDP_setPaletteColor.
I get CRAM dots somewhere around line 192...what's up with that?

Do you have them in-game and always or only in some situation (level loading / palette fading...) ? If you have them in-game then I think you have some code somewhere writing CRAM and you probably forgot about them (old debug ?). At least the SGDK sprite engine never write it...
Another possible problem is that VInt callback take so much time to process that it return well after the VBlank end and so you colorCyclePressStart(..) method get executed in active area..

Stef wrote: Tue Aug 28, 2018 2:57 pm Do you have them in-game and always or only in some situation (level loading / palette fading...) ? If you have them in-game then I think you have some code somewhere writing CRAM and you probably forgot about them (old debug ?). At least the SGDK sprite engine never write it...
Another possible problem is that VInt callback take so much time to process that it return well after the VBlank end and so you colorCyclePressStart(..) method get executed in active area..

This is most noticeable on the title screen, and I've never had any debug-col-writes there and I've been looking.
And this all works as expected on my PAL machine, but not on the NTSC one I got. Which is the Retroad retro genesis...which could be the problem here?

Retroad retro genesis ?? Oh definitely it would be better to test on a real NTSC Sega Megadrive, i think you shouldn't don't spent too much time with this

You can always mod a megadrive to be selectable both PAL and NTSC.

Found a modded PAL machine with a switch for 50/60 hz, at an auction site now, seems to have switch for overclock to 10Mhz as well. Never seen that before.
Do I dare buy it? It's not cheap either...

The retroad is a great machine, apart from the cram dots (which might not be a problem with the machine) I've had no problems with it. Got HDMI out which is perfect for my setup at my desk and wifi 6 button pads that fit my hands perfectly.

If you have soldering iron, just do the mod is very simple.

It's "simple" only if you have at least a vague idea about working with electronics...

But yeah, a region mod with switches is worth it (especially if the switches are exposed outside instead of needing to open the console). There are people who are willing to do the mod too. Just beware of the shipping price if you're sending your own console...

Stef wrote: Wed Aug 29, 2018 9:50 am Retroad retro genesis ?? Oh definitely it would be better to test on a real NTSC Sega Megadrive, i think you shouldn't don't spent too much time with this

Modded my PAL machine.


But the cram dots are still there. And since I can easily switch to PAL again now, I can clearly see the difference.
So, there is something going on with/at the vblank-wait. Anything else I can have missed?

I'll try to replicate it with a smaller program.

Do you have them in-game and always or only in some situation (level loading / palette fading...) ? If you have them in-game then I think you have some code somewhere writing CRAM and you probably forgot about them (old debug ?). At least the SGDK sprite engine never write it...
Another possible problem is that VInt callback take so much time to process that it return well after the VBlank end and so you colorCyclePressStart(..) method get executed in active area..

You may dig in that, maybe the vint callback take too much time (too much stuff to transfer) so in the end the transfert continue in active period (which is very slow) and the colorCycle method get executed after that. PAL system has much longer VBlank so you can transfer much more data.

Stef wrote: Fri Aug 31, 2018 7:35 am

Do you have them in-game and always or only in some situation (level loading / palette fading...) ? If you have them in-game then I think you have some code somewhere writing CRAM and you probably forgot about them (old debug ?). At least the SGDK sprite engine never write it...
Another possible problem is that VInt callback take so much time to process that it return well after the VBlank end and so you colorCyclePressStart(..) method get executed in active area..

You may dig in that, maybe the vint callback take too much time (too much stuff to transfer) so in the end the transfert continue in active period (which is very slow) and the colorCycle method get executed after that. PAL system has much longer VBlank so you can transfer much more data.

Yeah, need to check it. There're a few quite large sprites there and maybe it's because of the animations being at the same time. Is there a way for me to jack into the sgdk vint?

In other news, I got myself a HDMI capture card so I can get some proper footage of the game, here're some: https://www.youtube.com/watch?v=zquq98TtKhw

There's not that much slow down going on in that video, but I do have some performance problems especially when the wagon goes into flames and it has fired off a lot of bullets. But other than that I'm pleased with the result.
And as mentioned, I've got someone redrawing/reanimating the main character, won't make it into the demo, though,

And were are the dots exactly? I can't see them.

I think you need to understand one think, you being the developer have a distinct view of the game than players will have, a kind of a God view after that much time spend on it.

For example that font that you are using produces a bit of head ache. I think you need to simplify some letters.

If something (that notorious) isn't understand instantly we have a problem because some people will desist. You think you are targeting normal people, but your definition of normal has changed along the long development.

Think about why some products sell a lot an others don’t, when there isn't much of a difference.

Miquel wrote: Sat Sep 01, 2018 12:41 pm And were are the dots exactly? I can't see them.

They're most prominent on the title screen. In the game they're not as far down the screen as on the title screen either, but they do exist.

It was the sprites that was too large. Preloaded all sprites into VRAM now and we have no more cram dots on the title screen. \o/