New Release: Doom

[cobracon]

Full level in and working.
Doors can be opened but don't close yet.
Also, you can't pick up the armor or shotgun (or anything else).

This morning I felt the urge to put in some sounds so in the hour before work I extracted some sounds from the doom shareware wad and had them playing on the VIC (the PC speaker effects, but still - official Doom sounds!).

The framerate has dropped a little. I need to do some more optimization.

Sure would love to see a video of this. Would be cool if you had a development journal online. That way people could see all the time and work you put into programming this.

[tokra]

Code is a mixture of C and assembly - just like the original game!

Kind of wondering how that works. How can you code in C for the VIC? Does the C compiler create 6502 machine code?

[Kweepa]

I'm using cc65 which generates 6502 and has a decent standard library.
There's even a configuration for the VIC that generates the SYS stub and places the code in the appropriate locations.

See http://www.cc65.org/

Also, you can see the latest submitted source here:

https://github.com/Kweepa/vicdoom

(I think... let me know if that's not available.)

[darkatx]

INSANE!!!!

[Diddl]

I'm very impressed by vicdoom!!

How do you solve reading WAD files? As far as I know CC65 doesn't support fseek and such things?


Why didn't you try first a simplier thing like Wolf3d?

[Kweepa]

I'm not actually reading the original WADs. (It's 10Mb so it wouldn't quite fit on a 1541 disk ) I'm making simplified versions of the maps in my own editor. Ditto for the music and graphics. The sounds are processed versions (processed to increase the frequency range) of the pc speaker sounds, which I may add volume modulation to by sampling the wav files.

I prefer Doom to Wolf. Plus, there's already MOOD for the C64 which is essentially a Wolf clone.

[Kweepa]

Here's a music test:
http://www.kweepa.com/step/vic20/doom/testmusic.prg
Unexpanded VIC.
I ripped the note values and timing directly from the main guitar track of the midi file, but it doesn't include volume or pitch changes.

[tokra]

Here's a music test:
http://www.kweepa.com/step/vic20/doom/testmusic.prg
Unexpanded VIC.
I ripped the note values and timing directly from the main guitar track of the midi file, but it doesn't include volume or pitch changes.

Sounds quite impressive. Although I'd say it's a little fast. When I set the speed of VICE to 78% it sounded about right tempo-wise.

I think I remember the original PC speaker music was that fast as well, but 99.9% of the people will judge it by the midi-music they heard back on Christmas 1993

[Kweepa]

Excellent ear!
The tempo of the original was 141 ticks per second.
I divide the tick values by 3 and run it off the 60Hz timer, so I in effect increase the ticks per second to 180.
141/180*100 = 78.3%!

I'll see if fixing the tempo breaks the note lengths. I'll also try adding a drum track.


Whoa... there was PC speaker music?? Must investigate! [EDIT] Seems not


[EDIT2] Updated the prg with the correct timing!

[Kweepa]

Progress report:
Sound and music with volume controls are implemented.
Doors open and close, and prevent progress when closed.
Drew all the sprites for the possessed human, pain and dead sprites.
Added menus.

The big items remaining are AI, picking stuff up, and more levels. Oh, and some optimizations.

[orion70]

Seeing the title screen is impressive: I never even dreamed this could be possible.

[tokra]

Man, this is really coming together. Keep it up! Even at 3 fps this will be the most brilliant VIC-20 game ever!

[Kweepa]

Last night I ran out of memory while working on the AI.
Here's a rough memory map, from memory:

1000-11FF screen
1200-13FF start up
1400-15FF font
1600-17FF screen buffer
1800-19FF back buffer
1A00-25FF map data
2600-35FF textures
3600-38FF math look up tables (log, exp, sin)
3900-41FF music
4200-44FF sound effects
4500-7CFF code and misc data
7D00-7FFF C stack

I'll probably have to cut one of the creatures (the pink beast - because it fit the palette worst) to save on some textures and sound effects.
I might cut the music in half, or break it down like a mod file into identical segments - that's a pain to do automatically, but I might get 1k or so back.
Obviously converting some of the code from C to assembly will get me some space savings. My limited experience suggests the code size would be cut in half for the converted functions.
Experimenting with a smaller stack is another option, but I'd only get back about 256 bytes I'd guess.
And of course there's stashing a few tables here and there in the lower 1k and the unused colour nybbles.
Whee!

[tokra]

Why not use A000-BFFF (block 5 = a full 8K)
32K expanders were pretty common back then and even Realms of Quest 3 uses it

You could also use 0400-1000 (block 0 = the 3K block), though the standard 32K expander I use can only use either block 0 or block 5. Final Expansion and Mega Cart offer 35K expansion though.

I don't know how much of the color-RAM you use but usually only about half of that is used for display and the other half can be used as a 4-bit memory.

Then there's always the tape buffer from $0334-$03ff and other areas in the lower 1K you don't need when BASIC is disabled.

Would be a shame to cripple the game when there's still so much memory unused. I'd consider a fully expanded VIC (+35 K) fair game for such a project.

[Kweepa]

Whaaa?
There's another 8k available??!
Hooray!
I thought I just had the lower 32k of the address space.

Thanks for the breathing room!
Although it will make the BBC micro port more challenging...

Time to go to town. Automapping is back on the design doc.