SpritesMind.Net

Hi all!

Just wanted to say a quick hi!

Former pixel artist that happened to get a little awakened interested due to spotting a Youtube video about Tanglewood. A couple of hours of googling around about new homebrew Megardive games and the scene and I am here.

A Megadrive game (COMBAT CARS) I did art for back in the days:
https://www.youtube.com/watch?v=ZT8J-C-pHh4&t=2052s


Goal
So what do you want? Apart from checking out and relax a bit.

Would be nice to do a Gunstar Heroes/Contra type of game demo. Maybe not a full game but get things up to try to push the hardware for some nice boss battles.

So I guess I will be checking around (very little spare time to probably just some hour here and there) to find:

• Setting up dev enironment: I guess it's ASM? saw something about C/C++ but can you push the hardware with that really=

• How/if to get the stuff up on a cart and into a real device

• Links to tips and demos / tuts / source of sprite multiplexing, scanline magic and such

I will start looking around but if anybody already can point me into some directions (you probably read those requests over and over again) of links etc I would be happy

Cheers,
Iridon

Massive, massive welcome! Wow, an original Mega Drive developer!

You're in the right place. Quickest way to get started with ASM is either my Hello World sample w/ workshop (here: https://bigevilcorporation.co.uk/2018/0 ... ld-sample/) or Jon Burton's scroll demo and short explanation video (here: https://www.youtube.com/watch?v=PSYhSmXBgIw). The latter throws you into the deep end a bit but at least you get something on screen in 5 minutes which is good for morale at least.

The popular C environment is Stephane's SGDK (here: https://github.com/Stephane-D/SGDK)- don't let C put you off, his framework has proven itself time and time again to be pretty flexible and quick enough for most. It all depends on how you use it. You can write bad code in any language.

Grab yourself a handful of emulators, all of them have their own quirks and various debugging features, and I'm afraid none of them are perfect. For debugging I use Regen - I like its 68k debugger (https://segaretro.org/Regen), for full playthrough testing I use BlastEm - quickly gaining traction around here for being the "best of the bunch" (https://www.retrodev.com/blastem/), and for very tricky bugs that only happen on hardware I use Exodus - a cycle accurate emulator, but you need a beefy machine to run it at a reasonable speed (https://www.exodusemulator.com/).

To test your game on cart, most people use an Everdrive, or a Krikzz Flash Kit (both at http://www.krikzz.com/). Neither currently offer debugging support, though.

There aren't many tutorials for stuff like sprite multiplexing or raster effects, we've mostly been winging it as we go. I could post some of my routines if I get a chance.

What was it like working on an MD game back in the day? Do you vaguely remember the process and what tools were used? I love hearing about this kind of stuff!

You can use both asm and C, in the same project. C for fast coding, and asm for cpu demanding parts.

Concerning the type of game you are planning, if you plan to sustain, let's say, more than 5 actors/objects on screen probably the most demanding part will be collision detection. Or any other n^2 algorithm, like sorting the mentioned actors (which perhaps you won't need). Those are good candidates to do in asm.

I don't know about you, but quite a lot of people (most coming from PC developing) have in mind doing in real time work that could be done before, in compile time or even before. That's the real trick, the language is secondary.

Also destroying actors once they are out screen (or put them into respawn array) is an example of techniques to cut down cpu demand absolutely necessary for this kind of project, you will discover all them along the way.

In other words, who you structure the program is much more important.

Collision is not necessarily n², more often than not you don't need everything checking collisions against everything (sometimes it may be true, but not always). Of course to take advantage of this you'll want to split objects into groups so you can easily scan only through the groups you're interested on.

EDIT: though the above brings up another point, a better algorithm will be more important to speed. Using asm is mostly a last resort thing if you're not comfortable with it.

Yeah! you are right, you can check collisions "everybody vs everybody" or knowing the type of game do something like this:
- main character vs foes
- main character vs foes shots
- main character shots vs foes

Some games differentiate "foes" and "foes shots", others not. Anyway, the thing is "main character shots vs foes" is very close to "everybody vs everybody", so it's not a truly n^2 but very near. Still one of the most cpu demanding parts, if not the most for this type of game.

There are even more techniques, but you can't escape from the "n*(n-m)" like order.

You can hopefully escape the n² complexity for collision, you can use screen partitioning to compute collision only on adjacent screen 'cells'.

Stef, just out of curiosity:
- What happens when an Actor resides in between two cells?
- What happens when an Actor is big enough to fill more than one cell?

Clearly there are solutions to those problems but we are trying to keep computation restricted, that's where I don't see the puzzle fit.

In my TD demo, actors only reside in one cell, but when searching the searcher's radius determines how many cells to check.

Normally you define your cell size depending your actor size, and so cell size should be equivalent to the biggest actor less or more..
When adding actor to cell, you have to consider using the actor mass center / barycenter to find which cell own it, when you do collision checking don't forget you check against current cell and all adjacent cells as well
For boss (which are probably bigger) you can use specific collision test code

BigEvilCorporation wrote: ↑

Tue Mar 27, 2018 10:26 am

To test your game on cart, most people use an Everdrive, or a Krikzz Flash Kit (both at http://www.krikzz.com/). Neither currently offer debugging support, though.

Hi,
I just freshly began learning Assembly. Hard task but I enjoy.
I could display tonight the 512 colors of the Megadrive one by one on screen But I only displayed this on emulator.

I wonder if I can try my Roms without any risks on CRT TV with my Megadrive and a Mega Everdrive.
Let say that my Assembly code is full or errors (memory errors, etc), is there a risk to damage the Megadrive or the Mega Everdrive as it is really near to machine code.

Sorry for this noob question
Thank you
TAMA

Stef wrote: ↑

Sun Apr 08, 2018 4:09 pm

Normally you define your cell size depending your actor size, and so cell size should be equivalent to the biggest actor less or more..

... using a 2^n number to use shifts instead of divisions.
Using that idea and after doing some math, it tells me that taking a very usual 80 px tall then you will have to do a check against more than 66% in average of the screen area. And well, it's at least 2^n complex, for this very specific scenario (MD, contra style), because you need to put every actor in a cell (n), then for each actor (n) do the collision check against other actor (0.66*n).

The formula:
- main character vs foes
- main character vs foes shots
- main character shots vs foes
was the most used by shooters on MD days.

Another thing is for other types of games those ideas don't require to conform.

80 px cell is quite big indeed, and having ^2 size is better.
Usually we use 16x16, 32x32 or 64x64 cells (and 64x64 cells is already quite big).
If some sprite are really bigger than max cell size then you can also add your sprite to several cells.
Having too large cells almost kill the point of doing partitioning, still you have to find the good trade off (it can becomes complex to handle partitioning by itself).

Make the cells too small and you may end up using too much memory, depending how you're implementing it.

The trick is to come up with the largest cell size that is not likely to end up with too many active objects at once. What this size is will depend heavily on the particular game (i.e. how much stuff the maps contain).

This is a pretty good answer for this last dilemma:

https://forums.nesdev.com/viewtopic.php ... 86#p239757

The only thing is MD/Genesis has a limited cpu and ram, compared with modern ones, so the solution has to be restricted to something smaller.