I decided I’d learn how to program for the Sega Mega Drive.

Soon afterwards I decided I’d port my entry to it.

This is probably 3 days of work, and has exactly 1 glaring bug I know about that I’d like to eliminate. (It has something to do with scrolling. Bet you won’t find it.)

So here it is: Sega Mega Drive port, beta #1.

If you can fix the bug, let me know (it comes with source code, and can be compiled with asmx – if you wish to change the Z80 sound driver, you will need to compile that separately).

It’s called “Cave Wanderer” because I had to pull a name out of my ass.

It’s for the Sega Master System.

I’m not going to recode scrolling in a 48 hour timeframe ever again. Which means this’ll probably end up being base code for the next time I feel like doing this for Ludum Dare.

But I’m totally keen to try this platform a third time.

Oh, and here’s a link to the game.

They’ve been somewhat working since the 3 hours left mark, but they’re here! I currently only have a door, a key, and a vertical barrier (not shown).

I think it’s killing the CPU a bit, though (we’re talking ~3.57MHz here for 60fps… PAL has it a bit nicer, ~3.54MHz for 50fps).

Download dump #005! (while I hang out the washing and grab lunch)

Wow crap, this is starting to look like a game now. Not mentioned in topic: platforms work now. You can’t shoot anything yet, sadly, and there’s no storyline at the moment.

See if you can get past all 254 killscreens. Download dev dump #004 here.

Have a cat.

Inability to make the bed aside, I have to make this into a game now. “I’ve got a rocket, let’s go!”

10:30pm, 16.5 hours to go. I’ve made the background look a little less bloody horrible (tbqh I felt like shoving in the most horrible pattern I know of, that bloody awful one you get when you start X11), added in some spike graphics, and I think that’ll do for now.

Tomorrow I aim to have some way to die when you get hit by spikes. Goody!

With 17.5 hours remaining, and 9:30pm on the clock, I finally have scrolling working!

This is exciting, because I don’t actually have an easy-to-address framebuffer or a mega-fast CPU.

In fact it’s so exciting that I’m giving you development snapshot #003. Enjoy. Note that I disabled the ground check for jumping; this is so you can see the awesomeness of bi-directional scrolling.

I’ve been working on object-to-terrain collision since this morning and it’s been working. Also made some of the player stuff  more generic, so now it should be possible to add objects that, um, act more generically.

With respect to the generic stuff, I’ve also made it have velocity and target velocity (which is actually harder than acceleration, but a bit nicer).

But wait! Just in the nick of time (read: about a minute after the 24 hour mark), I got jumping working! And by jumping, I mean it actually detects that you’re on the ground, as opposed to having a magic jetpack.

What’s there:

• Object-to-terrain physics, and not just on the object bottom; there’s a total of 4 pixels checked!
• Gravity!
• You can jump!
• You can’t jump in midair!

What’s not:

• Still need to work on level scrolling.
• Needs more objects.

What might be there:

• Due to me fixing a VDP-related race condition, I think I’ve made it able to load levels that aren’t 16 level tiles wide.

So here’s development snapshot #002. You will need an emulator to run it (linked again just in case you’re not following).

For those of you who have an emulator for the Sega Master System, I’m releasing development dump #001 of my game.

What’s there:

• Music engine from my LD19-derived base code
• Working level loader
• Offscreen objects don’t appear on screen
• You can move the player around

What’s not:

• The level does not scroll (needs to be able to draw individual rows / columns)
• It won’t draw levels correctly that aren’t 16 level tiles wide
• Physics are broken at the moment and thus dummied out (tile collision data is there, though)
• Objects and functions pertaining to them need to be more generic. Apart from collision detection, which doesn’t even work yet, all the functions that operate on objects directly interact with pointers pointing to the player object.

So good night guys, and hopefully I’ll be in bed before tomorrow rolls over.

So, the game can currently load and render a 16×12 level.

It’s harder to do than it looks.

I would like to get larger levels working, but for now physics are a bigger priority. The data is there, it just needs to be used. I think I’ll need to add in some slope dirt tiles though, which is one place where the tile flipping capabilities of the VDP may come in handy.

Although to get THAT working, I need to be able to move the player around. I think I’ll need to pull out something like that OO framework I used in LD19.

In other news, I’ve shifted the player graphics handling stuff to a VBlank interrupt handler.

Oh yeah, I’ve had some music playing for quite some time now. It starts with the equivalent of 6 channels worth of echo (then drops to 4 due to the bass). Have a listen.

I’ve filled in the other 3 frames required, and set it up so that it only loads one frame of animation into VRAM. There are enough scanlines to do this completely in VBlank with a comfortable amount of headroom; unfortunately, the method used isn’t fast enough to require me to slow it down during not-VBlank, and so this provides no speed advantage.

Anyhow, on the topic of sprite flipping. The TMS9918A provides a lovely feature which allows you to flip tile data horizontally and/or vertically. Unfortunately, this was not provided with sprites, despite the fact that there’s a blatantly unused section which would have been perfect for sticking these flags in. So you have to flip the sprites manually.

This is where we use a table to perform the flip. It looks like this:

(╯°□°）╯︵ ┻━┻

Erm, I mean THIS:

.macro m_build_fliptab_gen
.redefine mv_q 0
.rept 256
.redefine mv_x mv_q
.redefine mv_x (((mv_x<<1)&$AA)|((mv_x>>1)&$55))
.redefine mv_x (((mv_x<<2)&$CC)|((mv_x>>2)&$33))
.redefine mv_x (((mv_x<<4)&$F0)|((mv_x>>4)&$0F))
.db mv_x
.redefine mv_q 1+mv_q
.endr
.endm

I also have one which generates a “no flip table” which is just a bunch of bytes from 0 to 255.

Here’s the code:

ld de,$0000
–:
.rept 4
rst $08
.endr

; load sprite
ld hl,$4000 + ($7C * 32)
ld bc,$80BF
out (c),l
out (c),h

ld hl,g_spriteset_plr
add hl,de
push de
ld d,fliptab>>8
-:
ld e,(hl) ; 19
inc l ; 23
ld a,(de) ; 30
out ($BE),a ; 41 – SAFE
djnz – ; START: 12
pop de

ex de,hl
ld de,$0080
add hl,de
ex de,hl
ld a,d
and $02 -1
ld d,a

; there’s still plenty of breathing room
; mednafen reports $DA with the occasional flicker of $D5

jp –

I hope you can work out whether the walk animation is any good or not. I’ve loaded it into an unused space of VRAM. If you look carefully, you’ll notice that one of the frames involves the player bobbing up. See, I put in effort!

As you may be able to delve from this screenshot, I kinda suck at graphics.

I think I’ll use this “severely deformed” style for now, and if I ever find a way to improve on it within the timeframe I’ll consider it.

Yes, I am using a text editor for my main graphics editing.

I’m using a cleaned up version of my Ludumdare #19 entry as base code, except it has NTSC detection and slows down the music for those machines.

Base code with base font and bassy test music

So yeah, unless I’m otherwise not in, I’m in.

My target platform is the Sega Master System, and I will be coding in Z80 assembler. I have done this before, and it is not as hard as you think.

Tools:

• Text editor: Kate / KWrite
• Emulators: Kega Fusion, clubsms (unreleased), Mednafen, possibly Meka too
• Assembler + Linker: WLA-DX
• Music: SchismTracker + it2vgm.py + muscomp.py
• Graphics: probably going to use the text editor
• Other tools: Python 2.x, of course

Anyhow, wish me all the best, because I’ll need it

There’s a new version of Autotracker available, and it actually looks like it can still be improved.

Introducing Autotracker-Bu: http://gm.64pixels.org/stuff/atrk-bu.py.txt

Features:

• Makes music for you!
• Occasionally gets stuck in an infinite loop! (actually a bug that shouldn’t be a big fix)
• Sounds better than Autotracker-C!
• Song title generator (includes “kittens” in its diction)!
• Varying speeds!
• Funky basslines!
• Reticulating splines!
• Adjective nouns!

If you wish to convert this to some sampled audio format, use something like SchismTracker to export to .wav (F9 to load, Shift-F10 to export to .wav), and then convert that to whatever you like.

If you wish to convert to MIDI… modplug might be able to open it? I’ll consider adding in a midi export mode.

So if you’re struggling to make music, save our ears and try this. It might even win an award!

Oh yeah, you’ll need Python 2.x to run it. Enjoy.

…I’m now able to share you a lovely link.

Alpha #001

Even includes a Windoze binary, which is the only thing I did to this game today.

Here’s that screenshot again:

Have a screenshot.

Also have some music.

Declaration of crap.

• Language: C
• Main lib: Allegro 4
• Sound lib: libdumb
• Music tool: SchismTracker, as usual
• Codebase: None

That’s all you really need to know.

I can safely say that this screenshot took WAY too long to process.

What were you expecting, something intelligent?

Anyways, there’s a nifty little hook system there, which should be sufficient for the framework I’ll be making.

With that said, I’m going to bed. Good night guys.

SB16 has been giving me hell. I thought I got direct mode working but it can only have so much shoved in before it gives in.

So I’m going to make an IRC bot game now.

So I’m basically learning how to program the SB16. I have done at least two floppy disk drivers, one which only reads one side of the floppy when not on an emulator, and the other doesn’t work at all on the real hardware. But I know how to do DMA… or at least knew, I’ll need to relearn it or something like that. (The floppy is the reason why you can’t use DMA 2 for Sound Blaster, IIRC.)

On top of that, there’s a main menu screen, a Level edit screen, a Gfx edit screen,  and a Sample edit screen.