New Release: KWEEPOUT

[tokra]

Woohoo, Stretch (and shrink even), a gun and a much more sensible aspect ratio. Loves it Only thing missing now is Paddle-support (hint, hint)

Again, don't forget the announce in the Sofware Releases of 2012-thread. In the years to come this will be where people are looking

Regarding speed of C... I like to show around your VIC-DOOM at demopartys and such and mostly get jawdrops of disbelief. So you think with pure assembly the frame rate could be twice as fast there as well?

[Kweepa]

I could probably speed that up quite a bit - something like x2 seems reasonable, yes. The column rendering part is in assembly already, but almost the same technique is in THE KEEP and that's much much faster, so it's not a factor. Collision and ray casting are the slow parts I think.

If I work on this again, I'll probably switch it to THE KEEP style ray casting and collisions which are lightning fast since they're on a 2d grid. I don't think it would affect the maps too badly. I've been planning a RPG, but it hasn't really got past the planning/writing stages.

Anyway I spotted a couple of bugs in KWEEPOUT which are now fixed.
I'll post it to software releases now.

[tlr]

This turned out to be a quite playable game. Still miss the smooth motion though...

[darkatx]

That was a whole lot of fun man!
Great work!

[matsondawson]

Arghh, game over, but wait what's that? An extra ball present... got it, game not over anymore!

[Kweepa]

It's a feature!

[siccoyote]

Been playing with this, really neat little breekout clone.

Was a bit confused when I came here as I'd been playing the final release and here it said unexpanded, then downloaded the unexpanded first version. what a difference assembly makes.

Just wondering though what is the difference between using the 3k expansion and using the 8k expansion? Is 3k faster to access, just wondering as I was going to make a topic asking but this seems a perfect example. using the 3k expansion seems pretty rare, and it does mean changing the dip switches on my expansion card, so I was wondering if there are benefits to it?

[Mike]

Just wondering though what is the difference between using the 3k expansion and using the 8k expansion? Is 3k faster to access, just wondering as I was going to make a topic asking but this seems a perfect example.

All memory in the VIC-20 has the same access speed, one byte/cycle for the 6502. Especially there's no difference between RAM in the +3K and RAM in the +8K expansion.

What *can* make a difference - in BASIC! - is the possibly different length of literal address values in the POKE command. Adding one digit incurs an extra (hidden) multiply by 10 and adding another digit, which slows down their use. We had a thread somewhere, where adding a RAM expansion indicated a slowdown, which could however entirely be attributed to the aforementioned effect, which has of course no relevance to machine language.

Holding down a key has a much greater effect - the full matrix scan of the keyboard slows down the VIC-20 by 10%.

sing the 3k expansion seems pretty rare, and it does mean changing the dip switches on my expansion card, so I was wondering if there are benefits to it?

If you can make a program/tool/game run with a smaller RAM expansion, go for it.

Using +3K RAM is not as rare as you may think. It has the nice benefit, that the position of screen and colour RAM is unchanged from unexpanded, and you can define UDGs quite easily by lowering the roof. Doing UDGs with +8K RAM or more is a bit more complicated, but still possible. See here for more details.

[siccoyote]

Thanks for the explanation, not sure I fully understand it but get the idea.

Vic-20 is very odd with it's memory though isn't it? I don't know if the ZX81 had similar issues with it's expansions.

When I said it was rare I meant the amount of games I've found that are made for it from 1986 onwards. I am guessing many more games used the 3k expansion before then when Ram was more expensive.

[bdk6]

ZX-81 was much odder, WITHOUT any expansion!
The display memory was "dynamically allocated" to only use what it needed. Each line of video used enough bytes to go from left edge to the rightmost non-blank character. So, if you put a single character on each line at the left side, the screen would need 16 bytes, one for each row. If you put a single character at the right end of each row, it took 512 Bytes, half the memory!
My space invaders game was sideways: if you rotated the TV 90 degrees clockwise it looked much better.
The ZX video allocation thing went away with expanded memory (which I never had.)

[Mike]

... just a few corrections/additions (sorry for the OT): the ZX81 had a 24 lines with 32 characters each. With <3K free RAM (especially with just the on-board 1K or 2K), lines were stored compressed: the last non-blank character was followed by a Newline character. An empty screen thus took 24 bytes (+1 extra NL, IIRC), a full screen 24x(32+1) = 792(!) bytes (again +1 extra NL).

The Newline (NL) char was identical the Z80 HALT opcode and the ULA made the Z80 *execute* the text screen, reading it as zeroes (NOPs on the Z80!) until a HALT opcode was fetched, which halted the Z80 until the end of the current raster. The ULA though read the original data, also fetched the corresponding character definitions, serializing them to video. During HSync, a display routine triggered by NMI set up the Z80's program counter either for the same line again (so all 8 rasters of a text line could be displayed), or let it continue in the next text line.

If you though think the ZX81 was complicated to get anything on screen, you haven't seen what hoops code on the Atari 2600 has to jump through.