aboutsummaryrefslogtreecommitdiff
path: root/porting_ideas.txt
diff options
context:
space:
mode:
Diffstat (limited to 'porting_ideas.txt')
-rw-r--r--porting_ideas.txt50
1 files changed, 50 insertions, 0 deletions
diff --git a/porting_ideas.txt b/porting_ideas.txt
new file mode 100644
index 0000000..ecad971
--- /dev/null
+++ b/porting_ideas.txt
@@ -0,0 +1,50 @@
+
+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:
+
+- sprite and font bitmaps
+- level layout data
+- level names
+- possibly color data (using an atari palette)
+
+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).
+
+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.
+
+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.
+
+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)
+
+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.
+
+later on down the road, the engine should support original Jumpman too.
+the https://playermissile.com/jumpman/ project has a lot of good info,
+much of which will also apply to Junior. also there's x86 asm source
+for the PC version.
+
+much later, there should be a level editor for the engine. not one that
+can export levels for the original game like omnivore does for original
+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
+really only care about the original game.