SpritesMind.Net

I'm not talking about real-time scaling as i know the hardware doesn't support it but some older systems like the C64 were able to display sprites at double size, even stretched. Is this possible with Mega Drive? Is it even possible to implement software scaling with SGDK? I'm guessing it would be quite complicated like copying pixels etc...

I don't know if this is what you are asking for, but you can try. I did and i have good results, but slow if you update it every frame:
http://www.drdobbs.com/architecture-and ... /184416337

My nemesis - math! Haha. Thanks though, will see if I can work it out

SGDK only provides a software scaling method but it requires to use the bitmap engine and BMP_scale(...) method.
There is indeed no support for sprite scaling and honestly that would be too slow to be really effective.

Stef wrote:SGDK only provides a software scaling method but it requires to use the bitmap engine and BMP_scale(...) method.
There is indeed no support for sprite scaling and honestly that would be too slow to be really effective.

So more for backgrounds? I guess if I'm clever I could scale my roadside objects with that rather than using sprites. I could just redraw sprites like they did in the old days but I'll try to make it look as much like scaling as possible.

POLYGAMe wrote: So more for backgrounds? I guess if I'm clever I could scale my roadside objects with that rather than using sprites. I could just redraw sprites like they did in the old days but I'll try to make it look as much like scaling as possible.

Well, the bitmap mode use a whole plan to draw the bitmap buffer (where you can draw scaled objects) and you can use the other plan as you want (display the road and background for instance). But SGDK Bitmap mode limit you on 192 pixel vertical resolution (with a top and bottom black border), it also limit you to 256 horizontal resolution so i guess that is not something you would like to use for your game. Bitmap mode is more useful for basic 3D rendering for instance and 3D raycaster like games.
What you can do is dedicate a bit of RAM for your sprite object, scale them in software in RAM then send the scaled sprites data to the VDP. But given the tile Sprite tile arrangement in VDP memory, doing software scaling on that won't be very effective.

Yeah. I think I'll just draw bigger and bigger sprites and 'scale' them in gimp so it will at least look like I'm scaling them. I like the look of the sprites in games like Outrun (arcade version) how they get big and blocky when close. I just need to be careful of tile count as the ground is textured etc.

Manveru wrote:I don't know if this is what you are asking for, but you can try. I did and i have good results, but slow if you update it every frame:
http://www.drdobbs.com/architecture-and ... /184416337

I've also used this technique. If I remember correctly, it would instantly drop down to 30fps or less as soon as you started rotating one or two 32x32 sprites, even with optimized asm.

I could just update it every ten frames or something. I know it will look jerky but so does swapping out sprites for bigger ones.

Yes, scaling everything at real time simply wouldn't be feasible. It's mostly a matter of choosing what needs to be cut down.

One possibility would be to scale/rotate everything lazily:
- An algoritm would pick which sprites should have their rotation/scaling updated; the sprites whose last updated rotation/scale mostly differs from the targeted rotation/scale would be picked up first;
- Somehow, one would have to keep track of approximately how much time has been spent updating the sprites in the current frame; if a limit is reached, the remaining non-updated sprites would be kept as they are;
- Also, one could keep track of what sprites are currently kept on the VDP, and what are they rotation/scale; if there's already some sprite whose rotation/scale is similar enough to the desired ones, it could simply be reused.

I believe Road Rash had software sprite scaling. Wasn't the smoothest game but it worked well.

Yeah some games use real time scaling, Road Rash is the first coming to mind but Toy Story does it as well and in a very smooth way :
https://youtu.be/oWxAWEC4nkk?t=1521
Note the SNES version does not have this level, probably because it couldn't handle it.
Toy Story is very impressive on many aspect, it also features a very strong raycaster engine.

ehaliewicz wrote:

Manveru wrote:I don't know if this is what you are asking for, but you can try. I did and i have good results, but slow if you update it every frame:
http://www.drdobbs.com/architecture-and ... /184416337

I've also used this technique. If I remember correctly, it would instantly drop down to 30fps or less as soon as you started rotating one or two 32x32 sprites, even with optimized asm.

That's right. You can put on screen some 16x16 or 32x32 sprites but you can only show that in screen with about that framerate. If you try to add a player or so, it will be so slow, even after i optimized that code so much. If the console sprites did not save 2 colors per byte, it will be a lot faster.

Stef wrote:Yeah some games use real time scaling, Road Rash is the first coming to mind but Toy Story does it as well and in a very smooth way :
https://youtu.be/oWxAWEC4nkk?t=1521
Note the SNES version does not have this level, probably because it couldn't handle it.
Toy Story is very impressive on many aspect, it also features a very strong raycaster engine.

I used to have Toy Story. Looked amazing but wasn't much fun to play.

How do you think those games did the scaling?

EDIT: I had no idea it had those racing parts! That scaling is impressive!!!

How do you think those games did the scaling?

likely, at the race level using same principle of first-person-like level.
namely, ray casting (and mirror top\bottom of objects).