Decreased S-CPU Velocity: Real or Imagined?

[93143]

I'm still thoroughly convinced that it really wouldn't make a difference to have sub pixel coordinates or not. (you definitely want it for velocity though.)

But if you don't use subpixel coordinates, you don't get the benefit of subpixel velocity, because it can't accumulate across frames. The only other way is to fake it like Sik does.

[Drew Sebastino]

I'm still thoroughly convinced that it really wouldn't make a difference to have sub pixel coordinates or not. (you definitely want it for velocity though.)

But if you don't use subpixel coordinates, you don't get the benefit of subpixel velocity, because it can't accumulate across frames. The only other way is to fake it like Sik does.

That's what I'd do.

[Stef]

There are a few cases where there are too many faces in a line and it glitches up, luckily those areas are small enough to be overlooked.

Ah ok, so there is this limitation, still pretty impressive to see it running at 60 FPS and that big
I made my own 3D flat rendering engine and of course it just can't display at 60 FPS because of the required bandwidth to just fill the rendering area :-/

CPU grunt, pretty much =/ The VDP helps with stretching it vertically, but horizontally the rendering is pretty much the 68000 at work. All of this while the 68000 rotates the text as well... (there's a reason why the text animation looks wonky)

I looked back at the effect and it appears the whole checkboard effect is rendered in a single plan i don't see much repeated patterns and so really wonder how the 68000 can fed that much data in VRAM at each frame (and that is even with the vertical assisted stretching which could not always work depending the situation). I wonder if there is no trick about the color arrangement as using one plan with 4 colors immediately me though about 1bit being used per color then we can somehow precalculate different combinations... I need to investigate with a debugger :p

We were originally going to have both - the old low-resolution phantom bitmap (covering half the screen, with the other half being a parallax with some text) and then the high resolution one. We ditched the former because Sigflup beat us to having it in a demo so we needed to brag about doing something better =| (oerg wasn't happy about it, and technically it was my fault since I was the one suggesting to release the original idea since something like it was already being discussed in SpritesMind and I didn't want the credit to go to the wrong person when it was eventually figured out)

Yeah i remember the discussion on SpriteMinds, still having both could have been cool as well
Actually the method was even known from Sega staff, the "Blast Processing" actually comes from that, it's why I intentioned used the "blast" word here :p

A whole palette per line. The amount of sprites being processed goes down to about 30 per line (too few and the message around the planet flickers, too many and the "your emu suxx" message appears).

Ok so transferring 16 colors per scanline eat a bit more than half of the sprite capabilities, good to know
Actually in games which are not CPU nor sprite intensive (as RPG) that is a workable solution to have more very colored background (even if it requires tricky timing, when you have them it's done).

[Sik]

I looked back at the effect and it appears the whole checkboard effect is rendered in a single plan i don't see much repeated patterns and so really wonder how the 68000 can fed that much data in VRAM at each frame (and that is even with the vertical assisted stretching which could not always work depending the situation). I wonder if there is no trick about the color arrangement as using one plan with 4 colors immediately me though about 1bit being used per color then we can somehow precalculate different combinations... I need to investigate with a debugger :p

I'll just ask Kabuto...

Ok so transferring 16 colors per scanline eat a bit more than half of the sprite capabilities, good to know
Actually in games which are not CPU nor sprite intensive (as RPG) that is a workable solution to have more very colored background (even if it requires tricky timing, when you have them it's done).

Yeah would have to be not CPU intensive (and not sprite loading intensive either) because Overdrive does a CPU spin instead of relying on hblank interrupts (i.e. CPU is busy looping through the entire active scan in order to get the right timing). Maybe it's more doable when the palette changes only happen at some points on screen, then you can just spin around for a few lines instead of the entire screen.

[Stef]

Yeah would have to be not CPU intensive (and not sprite loading intensive either) because Overdrive does a CPU spin instead of relying on hblank interrupts (i.e. CPU is busy looping through the entire active scan in order to get the right timing). Maybe it's more doable when the palette changes only happen at some points on screen, then you can just spin around for a few lines instead of the entire screen.

Yeah it's why i specified that, requiring so accurate timing mean you have to spent CPU in waiting for the correct time and if you want to update 1 palette at each scanline then you really require to spent the whole active time on it.
Doing it each 8th scanline would already release a lot of CPU time (busy ~2 scanlines then free for 6).