aboutsummaryrefslogtreecommitdiff
path: root/porting_ideas.txt
diff options
context:
space:
mode:
Diffstat (limited to 'porting_ideas.txt')
-rw-r--r--porting_ideas.txt32
1 files changed, 19 insertions, 13 deletions
diff --git a/porting_ideas.txt b/porting_ideas.txt
index ecad971..c61512a 100644
--- a/porting_ideas.txt
+++ b/porting_ideas.txt
@@ -1,36 +1,42 @@
can't really do a pure game engine that just uses the binary for data,
because parts of the game mechanics are implemented purely as 6502
-code. also the sound effects would need the engine to execute 6502 code
-*and* emulate POKEY. however, it can at least use this much of the binary:
+code. however, it can at least use this much of the ROM:
- sprite and font bitmaps
-- level layout data
+- level maps
- level names
-- possibly color data (using an atari palette)
+- level graphics (girders/etc)
+- color data (using an atari palette)
+- sound effects & music
this stuff can either be read out of the binary at runtime, or be coverted
into source and/or config files when building the engine. either way,
the original game binary will be required, but doing it at build time
means you don't need the binary at runtime (engine will be a standalone
-port of the game).
+port of the game). I lean towards reading it at runtime, so people can
+modify the ROM to create their own levels (though, this won't work if
+the levels use new 6502 code).
the various specials (hail, hatchlings, invisible level, etc) will have
to be rewritten in C (or whatever the engine ends up being written in).
-probably just hardcode which specials appear on which levels.
+probably just hardcode which specials appear on which levels. actually
+the level data will tell us this, we just match up subroutine addresses
+in the ROM with functions in our code.
the basic game rules that don't change from level to level will of course
be part of the engine. running, jumping, climbing/descending ropes,
picking up bombs, collision detection, most levels have generic bullets.
-the sound effects and music can just be .wav files captured from the
-original game running on the emulator.
+the sound effects and music will be done with pokey chip emulation (see
+the stuff in pokeytest/). However, it might be nice to allow an option to
+use .wav files instead, which would let people use samples from the C=64,
+or I could get fancy and record myself playing the music on guitar...
I'm thinking C with SDL2. render the game in an atari-sized window
-(320x192 or whatever it really is) and let SDL2 scale it, which seems a
-lot nicer than SDL1's basically nonexistent scaling. other possibility
-would be perl-SDL, provided it's got full SDL2 support (not sure, seems
-cpan doesn't have it)
+(160x192 or whatever it really is) and let SDL2 scale it, which seems
+a lot nicer than SDL1's basically nonexistent scaling. Thought about
+perl-SDL, but there's no SDL2 support, and I really want HW scaling.
might add high-score saving a la original Jumpman (the one thing I really
missed, for the cart-based Junior). also maybe a randomizer mode.
@@ -46,5 +52,5 @@ Jumpman, though. unless that turns out to be easier than I think,
of course.
also inevitably someone will want updated graphics/sound, a "high res
-apack" dd-on or such. I'm not opposed to such a thing existing but I
+pack" add-on or such. I'm not opposed to such a thing existing but I
really only care about the original game.