1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
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. however, it can at least use this much of the ROM:
- sprite and font bitmaps
- level maps
- level names
- 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). 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. 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 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
(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.
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
pack" add-on or such. I'm not opposed to such a thing existing but I
really only care about the original game.
|
