From 26b42926816662ce878e814938a1ebc0aa1847c2 Mon Sep 17 00:00:00 2001 From: "B. Watson" Date: Mon, 29 Aug 2016 15:00:13 -0400 Subject: finally made a git repo for this --- porting_ideas.txt | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 porting_ideas.txt (limited to 'porting_ideas.txt') 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. -- cgit v1.2.3