SpritesMind.Net

Hey guys,

I'm trying to find a way to render my tiledata double sized (save tiles in vram), all I can find is sprite.size, which states it doesnt work for now, and you can only use it as size>>8.

Am I missing something, or not?
Am I wrong in assuming .size should scale, and if so, is there any ETA on that feature?

Kind regards,
Dennis

Hi there,

I'm assuming you're talking about the SGDK? The size in that case specifies the number of tiles the sprite uses in the structure. It doesn't specify a scale amount. The Genesis doesn't have any kind of hardware scaling feature.

DJCC

..

You can eventually use this method :
But it is intented to use with bitmap mode and that is definitely not really fast.

I am indeed using SGDK, and have no knowledge of assembly, so that's kind of an issue :p
The VDP function, is that functional yet, or still wip? Any eta if not?

Thanks for the answers all!
-D.

In general, on the MD the artist is expected to scale any artwork by hand to make it look as good as possible. On the SCD, there is an ASIC that can do scaling and rotation for you.

Helghast wrote:I am indeed using SGDK, and have no knowledge of assembly, so that's kind of an issue :p
The VDP function, is that functional yet, or still wip? Any eta if not?

Thanks for the answers all!
-D.

One thing I want to make sure you understood is that the BMP_loadAndScaleBitmap() function is part of a special software rendering mode that Stef has in the SGDK. It's a software-based frame buffer. As it's done in software, it's quite slow, uses a fair bit of memory and you have to run at a lower resolution than normal to get ok performance. Stef can correct me if I'm mistaken, and he can definitely share more about it.

So, short version: On a stock Genesis, there are no hardware features for scaling sprites. There are techniques for faking it in various ways, but there is no easy-to-use, built-in feature.

djcouchycouch wrote: One thing I want to make sure you understood is that the BMP_loadAndScaleBitmap() function is part of a special software rendering mode that Stef has in the SGDK. It's a software-based frame buffer. As it's done in software, it's quite slow, uses a fair bit of memory and you have to run at a lower resolution than normal to get ok performance. Stef can correct me if I'm mistaken, and he can definitely share more about it.

You're totally right, thanks for explained it in detail

Thanks all for the replies!

Makes sense, I guess I am a bit too spoiled with engines etc nowadays
I just wanted to see if there's an "easy" way to save memory tiles, by loading an image half the screen size, and displaying it twice as big.

Doesnt matter, I'll think of a way to design a better system instead!
(I actually have an idea for loading big maps now).

Thanks for all the help guys, loving this forum so far, gave me a huge insight into the hardware so far

regards,
-D.

..

eteream wrote:RAM memory is really a restriction in old consoles. But the funny part is we humans become more creative if we have some restrictions, despite it sounds contradictory.

Usually the way to save memory is to repeat tiles or sprites. For example in some cases when a explosion happens on the screen you see lots of fireballs, but in memory there is just a quarter of an animation of a fireball (so every fireball is 4 sprites mirrored themselves).

I have done mobile games, not a big restriction as the megadrive, but certainly lots of trickery there like this.
I have though of several things similar to this kind of trickery

Next step is to write me a memory manager, with fixed entry definitions where to store certain data. Then on to see if I can get them tiling backgrounds to work ^_^

I love thinking creative like this!

regards,
-D.

Helghast wrote:

eteream wrote:RAM memory is really a restriction in old consoles. But the funny part is we humans become more creative if we have some restrictions, despite it sounds contradictory.

Usually the way to save memory is to repeat tiles or sprites. For example in some cases when a explosion happens on the screen you see lots of fireballs, but in memory there is just a quarter of an animation of a fireball (so every fireball is 4 sprites mirrored themselves).

I have done mobile games, not a big restriction as the megadrive, but certainly lots of trickery there like this.
I have though of several things similar to this kind of trickery

Next step is to write me a memory manager, with fixed entry definitions where to store certain data. Then on to see if I can get them tiling backgrounds to work ^_^

I love thinking creative like this!

regards,
-D.

It might interest you to know that there exists Propeller, an SGDK-based game engine.

viewtopic.php?t=1373

Quick feature list:

- 8-way scrolling engine with "special tiles" the player can interact with like coins.
- object management system with per-object type collisions
- contains examples of effects, level structure, tile collisions, projectiles, enemy AI, player handling, animation, rotations and distance calculations
- python based tools to generate sin/cos and distance tables

It's not perfect and has sadly too little optimization. It's meant to be used as a example and as a base to start new projects. It usually goes that you'll probably want to write your own stuff, but you can definitely dig through the code for ideas. Certainly the code for 8-way scrolling of large maps will interest you.

Thanks, I was actually looking at that before.
I am still having a hard time understanding scrolling, but I'll make a new topic for that at some point, first wanna try out some tests

regards,
-D.