Denial

Demo for unexpanded VIC (pal and NTSC), with source.



http://www.kweepa.org/step/vic20/vicwolf.prg

Source here:
http://www.kweepa.org/step/vic20/vicwolf.zip

Developed with CBM Prg Studio. Thanks ajordison!

Very cool!

Nice one, indeed!

Even "he" is there.

I see you make a correction for the slightly misplaced standard position in NTSC (to the right side and downwards) which is quite visible in VICE at least. Otherwise you could have omitted the PAL fixup code by using offsets from the ROM table, of course.

How about adding an entry for Software Releases in 2011?

This is really fun. I don't know why it's a demo and not a game . I know this is probably related to another game I haven't played (hey, they didn't make a vic version), but I like the idea of it being an original game. I was really blown away when I first saw Capture the Flag. I think the textured walls of this program are much more engaging, and of course, it moves a lot faster too.

This should definitely become a game!

Just WOW!

There's not a whole lot of room left for a game in the 3.5k
The memory map is basically:
0100-0180 free space
0200-0400 free space
1000-1600 code
1600-1800 textures
1800-1C00 level map
1C00-1E00 UDG
1E00-1E80 screen
1E80-1FFF free space
9400-9600 free space

I was considering making a random map using a similar technique to Whack, and storing it at 9400 (the map is currently 32x32 but I could cut it down to 22x22). That would free up 1k for an enemy and some game logic. Having an enemy on screen would probably halve the frame rate Some music and sound effects could go at 0200.

Kweepa wrote:There's not a whole lot of room left for a game in the 3.5K

Hmm, but if you fully expand the VIC, it quickly becomes VIC DOOM again. Speaking of: VIC WOLF looks a lot faster than VIC DOOM. I suppose this is due to a smaller display area, no music or enemies and the engine being done in Assembler rather than C. Or are there other fundamental differences? Can (or will) the WOLF-engine be used in VIC DOOM as well?

tokra wrote:... if you fully expand the VIC ...

Maybe a +3K RAM expansion is sufficient, if code and data for a playable game cannot sensibly be packed into the unexpanded VIC-20.

With random level maps one loses the recognisability of maze locations. Somehow then it always looks the same, regardless where you are. I'd rather much prefer an explicitly stored map, maybe even level files and a corresponding editor.

tokra wrote:Hmm, but if you fully expand the VIC, it quickly becomes VIC DOOM again.

Indeed. I wanted something a bit simpler.

Speaking of: VIC WOLF looks a lot faster than VIC DOOM. I suppose this is due to a smaller display area, no music or enemies and the engine being done in Assembler rather than C. Or are there other fundamental differences?

Yeah, Wolf is about 8-10 FPS I think. Doom is 1-3.
The big differences are
- no enemies
- renderer is ray casting rather than portals
- fixed point maths, no divides required, and only four multiplies per column
- faster texture mapper (about 32 cycles per pixel versus 47)
- wall collision handling is trivial
The display area is exactly the same - 8x8 UDGs.
The music doesn't have a big impact on the speed.

Can (or will) the WOLF-engine be used in VIC DOOM as well?

I was considering changing Doom to use this renderer, but it would be a shame to lose the arbitrarily angled walls. I can definitely use the texture mapper.

Mike wrote:Maybe a +3K RAM expansion is sufficient...

No! Unexpanded all the way for this one.

With random level maps one loses the recognisability of maze locations.

True. Perhaps I could store some seeds that produce nice maps. Or use Astronell's technique to store a few interesting levels by overlapping graphics character shapes from the ROM.

Kweepa wrote:No! Unexpanded all the way for this one.

You never know, anything can happen.

Kweepa wrote:I was considering making a random map using a similar technique to Whack, and storing it at 9400 (the map is currently 32x32 but I could cut it down to 22x22). That would free up 1k for an enemy and some game logic. Having an enemy on screen would probably halve the frame rate Some music and sound effects could go at 0200.

And how about a 3D version of Whack, with turn-based actions upon encounters with monsters or objects? Enemies would be handled by a different routine, so movement/exploration would be just as smooth as in this demo .

Random maps (not yet coded in asm):

Is there any way to compact or crunch the screens?