Hi - first post, with a whole bunch of questions...

[skroooagh]

Hi! A bit of Googling led me here and I have to say, you guys really seem to know your stuff! I hope my obviously n00bish questions aren't too annoying, heh.

Recently I've been thinking about what great memories I have of the 16-bit video game era and how I always dreamed of making my own game back then. I've decided that I'm going to try to achieve my childhood dream of releasing a game for the Megadrive and/or the SNES (preferably both, although I'm definitely a Sega guy), with a proper cartridge release and all. I have endless ideas, but for my dream to become reality I really need to start working sooner rather than later.

With that in mind, here are a whole heap (hopefully not too many) of questions, which I'm sure you've answered to death, but I'd really appreciate your help.

***Which is the most reliable emulator for ROM testing? By that I mean, which will most accurately indicate what will and won't work on actual Genesis hardware. Or, should I just get a flash cart?

***What are the "must-have" tools/programs/documents I should check out in order to create a good dev environment? I've had a look and a lot of the utilities seem to perform similar functions, and I really don't know what I should be looking for anyway, so, what do you reccommend?

***From what I gather, there are generally two coding languages that need to be learned, assembly and C. Do both languages have a similar level of functionality? I guess one is a "beginners' code" and one is not?

***Finally, what would you say are the most advanced/"professional" MD homebrew games around? I've found lots of demonstrations of various effects and such but no real games. I'm interested in seeing what others have achieved so that I can set realistic goals for myself.

Thanks in advance! I really appreciate it!

[Jorge Nuno]

Personally I use Fusion and Gens Kmod the first for compatibility test, the second for development/debugging

And yes you should get a physical rom support, build or buy a writable cart
__________
you must have a 68000 assembler(if ASM) or a C compiler for the 68000
depends on the language you prefer
you should get a z80 assembler too if you want to program the secondary cpu (you can get picture on the tv without it)

sega2f.doc is a doc that tells almost everything about the console

genvdp.txt is a VDP-only document you should get to understand the VDP commands easier, but the sega2f explains it too

For ASM language there is a 68000 quick reference which is a pdf of 2 pages with all 68000 instructions and details about them

There is a program called VDPregscalc that helps you configure the VDP:
Select what you want the VDP to do with checkboxes and the program will generate the corresponding register code

there is much more out there, wait for other's opinions
__________
Do you know ASM or C? (or none?)

If you have know how about hardware architecture the ASM language could be easier, if not first you need to learn the binary and hexadecimal systems first (For any language you choose)

ASM i think it is easier to learn, but what C does in one line, in ASM you need half-page of code to do the same (LOL)

In both languages you can do anything possible on the console
__________

LOL games are very difficult to do becuase they are big and complex
I think the games "homemade" out there you could count with your fingers

Goals for yourself it depends of your programing skills, texture making, music making
__________

Good luck in your quest

[8bitwizard]

Recently I've been thinking about what great memories I have of the 16-bit video game era and how I always dreamed of making my own game back then. I've decided that I'm going to try to achieve my childhood dream of releasing a game for the Megadrive and/or the SNES (preferably both, although I'm definitely a Sega guy), with a proper cartridge release and all. I have endless ideas, but for my dream to become reality I really need to start working sooner rather than later.

In my opinion, the Megadrive and the Game Boy Advance are probably the two easiest systems to program.

Which is the most reliable emulator for ROM testing? By that I mean, which will most accurately indicate what will and won't work on actual Genesis hardware. Or, should I just get a flash cart?

I don't think you can rely on any emulator to tell you what will and won't work. So you really need either a flash cart or a game copier unit (I think you can get both at tototek) to test on real hardware.

I normally use a version of SDLMESS to test my games during development. The plus is that I can run it from the OS X command line as part of the make process. The minus is that it doesn't support cartridge memory of any kind, so I have to have a fake battery RAM option in my code. I also sometimes use the NeoGenesis emulator on an Xbox, which does support standard battery RAM.

For final testing, I have a 16Mbit Multi Game Hunter with floppy drive, and actual EPROM cartridges. I also hacked up an old version of the MacsBug debugger which can talk through the EXT port for low-level debugging.

What are the "must-have" tools/programs/documents I should check out in order to create a good dev environment? I've had a look and a lot of the utilities seem to perform similar functions, and I really don't know what I should be looking for anyway, so, what do you reccommend?

Must have a 68000 assembler and a copy of sega2f.

This is my assembler: http://xi6.com/projects/asmx/
I have a touched-up sega2f here: http://xi6.com/files/sega2f.html

I haven't done C on it, but the good news is that gcc supports 68000. And the 68000 is very much like the PDP-11, which C was originally written for.

From what I gather, there are generally two coding languages that need to be learned, assembly and C. Do both languages have a similar level of functionality? I guess one is a "beginners' code" and one is not?

You don't have to use C, but you have to know how stuff works at the assembly language level to get your code started up (including how to start the C runtime if you use C) and how to use the interrupts. It would also be a very good idea to learn what the 'volatile' keyword does.

I've found lots of demonstrations of various effects and such but no real games. I'm interested in seeing what others have achieved so that I can set realistic goals for myself.

Here are my two main projects:
- http://xi6.com/projects/tubes/
- http://xi6.com/projects/rpg/

[skroooagh]

Thanks guys, there's plenty to get me started here!

I do understand the idea behind hexadecimal/binary but have never actually coded with it (or any other language) so I have a lot of work ahead of me, I'm sure.

Probably a stupid question, but, I run the assemblers/deassemblers through the command line? (I'm running XP)

Man, you guys will be so sick of me by the time I'm through, hehe.

EDIT: Oh, and I forgot to add, I tried out 8bitwizard's RPG and it looks like it'll be a fun game once it's done!

[TmEE co.(TM)]

You may also want to take a look on my site aswell http://www.hot.ee/tmeeco ... I need to update it...

There you'll find some great docs and some tools I use plus most of my projects which some have sources included (100% ASM though).

Emulators: I use GensKmod for development and debugging, and Fusion for playing.

Flash cart: a real must have, I built one for myself. You can't believe how useful one can be. I always stumble upon some unemulated stuff which are present on real HW only (address error exception most notably).

Programming: I write stuff in ASM only, as I don't know C... I use SNASM68K assembler for 68K code, and AS80 for Z80 code.
Assembly is not hard, just tricky sometimes

As 8bitWizard said, MD is really easy to program for.

[skroooagh]

Thanks again!

Another question:

***I've seen a lot of "fake mode7" stuff on MD games like Contra: Hard Corps and Castlevania: Bloodline, does anyone know how this works? I'm not looking for a walkthrough on how to do it or anything, and I fully understand that it will most likely take years fr me to be able to do so myself, just wondering if anyone has any idea of how it's done on MD and how easy/difficuly it is to impliment. I'd like to make a 2D fighter with a mode7-esque floor, surely that's simple enough for the MD to cope with? (if not my n00b brain, haha)

[8bitwizard]

I can only guess that "fake mode 7" is done the hard way, by pumping a bunch of 68000-rendered (or pre-rendered) data into the VDP and showing it on plane B. There's certainly no support for it built into the VDP.

You can use scrolling to make a background that can move around, or chain a bunch of sprites together to make a larger sprite, but if you want to rotate or zoom in, there's no way other than loading a pre-scaled image into the pattern table.

There is some scaling and rotation support in the Sega CD, but that only works on data in RAM, which still has to be copied to the VDP as pattern table tiles.

[Stef]

Thanks again!

Another question:

***I've seen a lot of "fake mode7" stuff on MD games like Contra: Hard Corps and Castlevania: Bloodline, does anyone know how this works? I'm not looking for a walkthrough on how to do it or anything, and I fully understand that it will most likely take years fr me to be able to do so myself, just wondering if anyone has any idea of how it's done on MD and how easy/difficuly it is to impliment. I'd like to make a 2D fighter with a mode7-esque floor, surely that's simple enough for the MD to cope with? (if not my n00b brain, haha)

fake mode 7 in Castlevania and Contra ??? hmm i guess you're speaking about that rasters effects on the intro screen.
Actually almost of the GFX effects are done by something we called "rasters effects". Actually that just consist of doing insane stuff during scanline retrace (as palette reprogramming, vertical scrolling offset change...)

[8bitwizard]

Not having played those games, I didn't know what he was referring to. Mode 7 is a SNES video mode which does 3D rotation and scaling of a background graphics plane. http://en.wikipedia.org/wiki/Mode_7

If you don't see rotation or perspective scaling, it's not Mode 7.

As for the interrupts used to make things wave back and forth, the Atari folks called them "display list interrupts", except that display lists are specific to Atari 400/800/5200/7800 graphics chips. Everybody else calls them horizontal sync (HSync) interrupts.

Basically they are done by changing scrolling registers or sprite positions in horizontal sync interrupts on specific scan lines. (Instead of interrupts, they can also be done by watching the VDP's scan line counter.)

[Shiru]

I think, skroooagh wants parallax scrolling effect on floors. It's simple linescroll - each line of BG has own X-offset, bottom lines scrolls faster than upper lines. SMD has hardware capabilities for this. Anyway, this effect is last thing to worry about when you plan to make fighting game.

[skroooagh]

I'll try to take some screengrabs/videos of the effects in the games I mentioned. You're right, they're probably more raster effects than strictly mode7, I just used "mode7" to refer to stuff that looks like it belonged more on a SNES than MD, heh.

Shiru, what I'm actually aiming to do is make a floor that rotates and shifts when a character moves almost as if it were a 3D trrain; if you've played Tekken Advance you'll know what I mean. I'm sure it's difficult but possible on SNES but I'm starting to think it just isn't possible on MD alone. And yes, I know that will be the least of my problems, I just think it's better to know what I could and couldn't do before I commit myself to anything.

This raises another question: coding a game in C should make is somewhat easier to port to another console, yes?

Once again, thanks people!

[Shiru]

Shiru, what I'm actually aiming to do is make a floor that rotates and shifts when a character moves almost as if it were a 3D trrain; if you've played Tekken Advance you'll know what I mean. I'm sure it's difficult but possible on SNES but I'm starting to think it just isn't possible on MD alone.

It's not difficult on SNES, because SNES has special hardware for this (MODE7 itself). For SMD it's difficult, because SMD does not have special hardware, so you must do all in software, with resources of main CPU. In result, you can make that effect, but it will work slow (much less than 50/60fps), maybe even unacceptable for game (here is also quality vs speed question).

Try to think about your idea from other side. What can such '3D' floor give to gameplay - i.e. is it really needed to make game?

This raises another question: coding a game in C should make is somewhat easier to port to another console, yes?

Yes, but only for game logic, and only if target platform has enough CPU power to run your code with acceptable speed. Console games usually do much direct work with hardware (VDP, sound, input), and hardware is very different on different consoles.

[skroooagh]

Try to think about your idea from other side. What can such '3D' floor give to gameplay - i.e. is it really needed to make game?

Well part of what interested me in having a 3D floor was being able to create a sidestepping action in a versus fighting game, so it's almost like a modern 3D fighter. I've always suspected that it would be best to leave that for something like SNES that can handle it with less fuss, but it would be cool to do it on MD just to show that it can be done. I guess I'll forget that idea for now though.

Yes, but only for game logic, and only if target platform has enough CPU power to run your code with acceptable speed. Console games usually do much direct work with hardware (VDP, sound, input), and hardware is very different on different consoles.

Hmm, that's what I thought, thankyou.

[Shiru]

Well part of what interested me in having a 3D floor was being able to create a sidestepping action in a versus fighting game

You can implement 'side-step' gameplay element without M7-like floor, there is many ways for it. You can do it in AoF style (almost beat-em-up), you can do it without rotating floor (with floor like road in racing games), etc.

[8bitwizard]

Basically there are two things that Mode 7 can do that the MD VDP can't.

1: it can stretch/squeeze a background plane horizontally - the VDP can only do 1:1 copying of pixels in the horizontal direction
2: it can display pixels from a background plane diagonally - the VDP can only display pixels from the same row on any scan line

Now that I've read how perspective was done with Mode 7 by changing the scaling/rotation settings on every scan line in an HSync interrupt, I realize that you could do a vertical stretching/squeezing on MD by updating the vertical scroll or sprite Y in an HSync interrupt. You could even shear the image sideways at the same time. But you will still only get 1:1 pixel scaling in each scan line, and no rotation.