mirror of
https://github.com/deater/dos33fsprogs.git
synced 2024-12-25 20:30:31 +00:00
152 lines
4.8 KiB
Plaintext
152 lines
4.8 KiB
Plaintext
Q1. Are you implementing the game just like the original (i.e. vector
|
|
drawing)?
|
|
|
|
A1. No, this is just a quick hack using sprites.
|
|
While it would be pretty amazing, I haven't written
|
|
a 6502 optimized vector drawing library.
|
|
|
|
---
|
|
|
|
Q2. Is the gameplay exactly like the game?
|
|
|
|
A2. No, there are a lot of things that are hard to do in 40x48 and/or
|
|
with only 48k of RAM.
|
|
|
|
See the TODO file for a list of things I've noticed.
|
|
|
|
The game is really amazing and subtle and some things you only notice
|
|
after staring at it a long time.
|
|
|
|
I haven't reverse-engineered the game code or looked at source code,
|
|
my version is made purely by observing game play.
|
|
|
|
---
|
|
|
|
Q3. Why aren't the keyboard controls the same as the original game?
|
|
|
|
A3. The Apple II has simplistic keyboard support.
|
|
In general it's not possible to read more than one key at a time.
|
|
Also on pre-IIe machines it's not really possible to get key-release events.
|
|
|
|
Additionally, on older models there's no auto-repeat unless you
|
|
hold down the REPT key, which makes running difficult.
|
|
|
|
The original game really depends on being able to detect having
|
|
multiple keys down at once.
|
|
|
|
---
|
|
|
|
Q4. Does this have joystick support?
|
|
|
|
A4. It should not be hard to add, and in fact would give controls much
|
|
closer to the original.
|
|
|
|
I probably won't have time to implement it any time soon though.
|
|
|
|
----
|
|
|
|
Q5. Is there anything impressive going on here, like with your other demos?
|
|
|
|
A5. No, it's pretty much straight up "sprite" drawing.
|
|
One unusual thing is I am using grey2 (color 10) as the transparent
|
|
color rather than black, as there is black in the sprites.
|
|
|
|
It's actually refreshing not having to cycle everything.
|
|
|
|
---
|
|
|
|
Q6. Why are some cutscenes tiny and some large?
|
|
|
|
A6. I started making the cutscenes before I had a good feel for
|
|
how large they'd be or how quickly they could run. Some of the
|
|
earlier ones are smaller for that reason, before I decided I
|
|
could afford full-screen ones.
|
|
|
|
---
|
|
|
|
Q7. How are you making the graphics?
|
|
|
|
A7. Using the original for reference (currently a Windows/EGA version
|
|
for some reason?) Size down to 80x48. (This isn't bad as the original
|
|
is roughly 320x200 which scales well).
|
|
|
|
I manually map colors to the Apple II Lo-res palette.
|
|
|
|
Finally fine tune in a bit while using original for reference.
|
|
|
|
|
|
---
|
|
|
|
Q8. Why lores graphics? It's so *horribly* blocky.
|
|
|
|
A8. Yes, but I like it anyway. So many colors!
|
|
I spent a lot of time as an ANSI artist so I am used to blocky
|
|
16-color graphics, and to be honest with you my art skills sort
|
|
of peak at that resolution.
|
|
|
|
Also Apple II graphics programming is painful and LORES is so
|
|
much easier than HIRES (it's also smaller, faster, and takes
|
|
less valuable RAM).
|
|
|
|
Partly nostalgia too, but my family only had a monochrome monitor
|
|
so I never got to experience full-color lores back in the day.
|
|
Unfortunately this game doesn't really play well in monochrome.
|
|
|
|
---
|
|
|
|
Q9. Are you going to make a version using Hi-res or Double Hi-res graphics?
|
|
|
|
A9. No, there's an official version for the Apple IIgs if you want something
|
|
like that. Apple II hires graphics with sprites are a huge pain
|
|
to program, would probably be slower, and would take up a lot more
|
|
RAM.
|
|
|
|
---
|
|
|
|
Q10. How about double-lores graphics (80x48)? It would give you almost
|
|
square pixels?
|
|
|
|
A10. While not as bad as Hires, double-lores is also a pain. It only
|
|
works on the IIe with 128k or newer. Also you now have to copy
|
|
things to aux memory, and your sprites have to worry about the
|
|
colors being shifted (I think) on the AUX page. It will take
|
|
twice the ram and probably run 1/2 the speed.
|
|
|
|
Also the current code uses page-flipping to avoid flicker/tearing,
|
|
but doing page-flipping in double-lores is really tricky.
|
|
|
|
---
|
|
|
|
Q11. Why are you targeting such an old machine, an original Apple II or II+?
|
|
|
|
A11. Well, I own one. Also there's something about programming on a machine
|
|
from 1977, whose graphics hardware is a glorified shift register,
|
|
and is implemented entirely out of 7400 series logic and 555 timers.
|
|
|
|
---
|
|
|
|
Q12. In the intro, why not have lowercase letters?
|
|
|
|
A12. The Apple II/II+ only supported uppercase letters by default.
|
|
Also no "|" character, which explains why some of the ASCII art
|
|
looks a bit odd.
|
|
|
|
I suppose I could auto-uppercase on older machines on the fly like
|
|
my Still Alive demo does. The memory budget is a bit tight though.
|
|
|
|
---
|
|
|
|
Q13. Could you really use this on an original Apple II from 1977?
|
|
|
|
A13. Yes, in theory. You would have needed a 48k model which would
|
|
have been expensive at the time ($2638). Also the disk image
|
|
will fail to auto-boot and HELLO won't run as it's in Applesoft
|
|
BASIC (not the Integer BASIC that came with the original II).
|
|
You'll have to manually type C600G and then POKE the level you
|
|
want to address 5 (0 for intro, 1 for LEVEL 1, etc)
|
|
POKE 5,2
|
|
then
|
|
BRUN LOADER
|
|
|
|
|