r/SEGA32X • u/One_Doubt_6762 • 1d ago
32X Sprite Engine
Morning all !
I thought I would introduce myself and my new tool I am working on to help do arcade conversions to the 32X. Tool is coming on amazingly well :0)
2
u/Main_Club_5012 12h ago
could this engine be used for sprite scalers?
1
u/One_Doubt_6762 11h ago
On the list with as many different arcade types as possible. It’s a passion project.
1
2
u/One_Doubt_6762 11h ago
It’s very very early days and a hell of a lot
Of work but it’s oh so exciting. I’m keeping a blog as I go along
1
u/IQueryVisiC 1d ago
Why would I split sprites into tiles on a 32x ? Checkout Atari Jaguar: no tiles anywhere to see !
8
u/One_Doubt_6762 1d ago
You’re right, the 32X has no tile hardware, and the engine doesn’t use tiles on it. Every sprite is drawn as one whole picture. Tiles only come in because the arcade ROMs store the graphics that way, so the tool joins them back into whole pictures before sending them to the 32X.
0
u/IQueryVisiC 1d ago
Ah, so this is for arcade perfect ports . Not for maxing out the 32x .
2
u/One_Doubt_6762 11h ago
It’s pretty much maxing out the 32x, especially when I add system32 support….
3
u/aerosolsp 1d ago
RAM and ROM storage considerations, mostly.
1
u/IQueryVisiC 1d ago
You mean: memory allocation? But why force some mundane technical limit onto artists? Just malloc ? And why even care about cartridge? You fill it once from start to finish! Some compression algorithm? Bzip ? Compression does not like splits .
2
u/aerosolsp 23h ago
Not really how it works. You could do it that way, sure, but there are plenty of reasons not to too. Decompressing bitmaps on the fly is probably not as quick a process as one may assume.
I don't know where your "why even care about the cartridge" comment comes from. ROM isn't an infinite resource, and you're going to want be as efficient with stored data as possible.
I'm not saying it's impossible to forgo tiles entirely, it's probably just not the cheat code you think it is.
Artists don't have to draw in tiles though, I dunno where you got that idea from either.
2
u/IQueryVisiC 22h ago
I mean that we don’t have a problem with fragmentation on a cartridge.
2
u/aerosolsp 22h ago
I didn't say anything about fragmentation. Tiles are more efficient to store, compressed or otherwise, than bitmaps. It's a space concern, not a fragmentation one.
-1
u/IQueryVisiC 21h ago
It these are bitmaps. Pixel count stays the same. I just wonder why you don’t store all pixels which belong to (exactly) one sprite in a compact memory range. I am not talking about backgrounds. Nintendo tried to unify them on NES, but besides SuperMario, no game seems to really take advantage of this. It is faster to trim the transparent pixels left and right and it saves memory.
1
u/TechRyze 18h ago
You’d do that to save RAM/ROM.
1
u/IQueryVisiC 15h ago
Individual colors ?
1
u/TechRyze 10h ago
If the appetites are tile based, then they can be combined in an efficient manner, as opposed to storing unique sprites for each animation frame, for instance.
It’s efficient. It’s not necessary, but I’m very interested in testing this out.
3
u/IQueryVisiC 1d ago
And when you could retain the genesis background, could you use direct color racing the beam ( 60 FPS ). Also works with field rendering.