diff options
author | B. Watson <yalhcru@gmail.com> | 2016-08-29 15:00:13 -0400 |
---|---|---|
committer | B. Watson <yalhcru@gmail.com> | 2016-08-29 15:00:13 -0400 |
commit | 26b42926816662ce878e814938a1ebc0aa1847c2 (patch) | |
tree | d4f451ab2820704f5b680b8ae0ceda037c78d9e9 /porting_ideas.txt | |
download | jumpmanjr-26b42926816662ce878e814938a1ebc0aa1847c2.tar.gz |
finally made a git repo for this
Diffstat (limited to 'porting_ideas.txt')
-rw-r--r-- | porting_ideas.txt | 50 |
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. |