New Release: KWEEPOUT

matsondawson · Post by **matsondawson** » Tue Jun 19, 2012 6:17 pm

Kweepa wrote: Oh, and for the emulated version, I realize now that I'm using the space character undefined, so it's liable to end up garbage. In VICE it seemed to be ok.

Ah yes, I initialise memory to $CE in my emulator... I'm guessing vice might zero it.

Kweepa · Post by **Kweepa** » Wed Jun 20, 2012 1:38 pm

New version with a bunch of fixes.
http://www.kweepa.com/step/vic20/games/kweepout.prg
(Why do my game release threads always end up with a bunch of technical discussion?

)

tokra · Post by **tokra** » Wed Jun 20, 2012 2:34 pm

Kweepa wrote:New version with a bunch of fixes.
http://www.kweepa.com/step/vic20/games/kweepout.prg
(Why do my game release threads always end up with a bunch of technical discussion? )

Isn't that a good thing?

Tried the new version - but I can't get to the second level. When all blocks are gone it will just stay on an empty screen not progressing to the next level.

You might also want to check the screen position. It looks like it's for PAL, on NTSC the screen is very much on the bottom. I suppose it won't show on real TVs. You could either use relative values or provide NTSC and PAL-versions

Regarding gameplay itself: Is it possible to change the angle of the ball depending on which part of the bat is hit? With very few blocks left you sometimes want a steeper angle, but it always seems to go at 45 degrees, which becomes frustrating after a while.

Getting technical again: You could maybe save some bytes if you use 5- oder 6-bit encoding instead of hex for the char-definitions.

Kweepa · Post by **Kweepa** » Wed Jun 20, 2012 3:27 pm

To uudecode some strings into UDGs:

Code: Select all

q=7520:forx=.to11:reada$:fori=1tolen(a$)step4:forj=.to3:p(j)=asc(mid$(a$,i+j,1))-32:next
pokeq,4*p(0)+p(1)/16:pokeq+1,16*(p(1)and15)+p(2)/4:pokeq+2,64*(p(2)and3)+p(3):q=q+3:next:next

(assuming each string is a multiple of 4 bytes long)
That's 141 bytes plus line numbers.
I have 136 bytes of UDG, which is about 272 bytes in hex strings.
Reduce that to 182 bytes uuencoded, saving 90 bytes. So could save fifty or so bytes, yes, given that the original code to decode the hex was about 100 bytes, I think.

I suppose I could define the characters, then reset the top of memory so that the variables overwrite the end of the program... I'd have to change the game over code to avoid "run", but it would save a fair bit I think. Has anyone done that? Any pitfalls?

As for the screen offset, oops! Looks like I'll be working on this some more...

Other angles for the ball... I tried it, and it looks terrible in basic. I may work up an assembly language version, with smooth bat and ball movement and multiple balls. Kweepout II. We shall see...

Kweepa · Post by **Kweepa** » Sun Jun 24, 2012 6:34 pm

At last I found some time to fix this up.
Here is a new version with the UDGs uuencoded and the screen offsets fixed.
http://www.kweepa.com/step/vic20/games/kweepout.prg
Made some other little tweaks here and there, but it's still horribly slow. I test it at 200% in VICE and that feels about right.

tlr · Post by **tlr** » Mon Jun 25, 2012 1:57 am

Haven't had time to test it before but I did just now.

This is a really nice breakout game. I like the graphics and game play but it is, like you say, horribly slow.

An optimized version of this, perhaps even with sw sprites would be brilliant in my opinion. SW sprites for the ball and the bat would be sufficient.

Kweepa · Post by **Kweepa** » Mon Jun 25, 2012 12:20 pm

Yeah, my plans for the assembly version are:
(a) bat and ball SW sprites
(b) different angles for the ball
(c) multiple balls pickup
(d) slower pickup drop, so it doesn't fall at the same speed as the ball
(e) better sounds, and possibly some music (which I am terrible at)
(f) keyboard control
(g) player bullets pickup maybe (dropped when there are only a few bricks left)

tokra · Post by **tokra** » Tue Jun 26, 2012 12:58 pm

Don't forget to post this game in the "VIC-20 Software Releases of 2012"-thread in the announcements!

I've just tried the new version. At 150% in VICE it's pretty playable. One little quirk still happens in rare cases, I'm still not sure when this happens exactly. But after hitting the ball with the bat at the very side of the screen sometimes the left and right borders are "opened" and the ball passes through it for. This corrects itself after some 30 seconds or so but still is pretty strange.

Looking forward to an assembly-version! I was gonna say the pickups should be slower since it's nearly impossible to get these at all, but you have this in your list already. With all the features you mention this could very well be a fully fleshed Arkanoid for the VIC. Yay!

Kweepa · Post by **Kweepa** » Sat Jun 30, 2012 9:41 pm

Here's a faster version (+3k):
http://www.kweepa.org/step/vic20/kweepoutmc.prg
I didn't do the smooth movement - I'll probably leave it as is.

Post by **Jeff-20** » Sat Jun 30, 2012 10:01 pm

I was kinda surprised to see a basic game from you. I really wanted to get one of the falling gifts, but they seemed to be perfectly timed with the downward movement of the ball. So, it was either the gift or the ball. It took a few rounds before I got the timing right. Downloading new version now.

matsondawson · Post by **matsondawson** » Sat Jun 30, 2012 11:49 pm

Impossible!

http://www.mdawson.net/vic20chrome/vic2 ... neType=pal

Kweepa · Post by **Kweepa** » Sun Jul 01, 2012 12:42 am

Jeff-20 wrote:I was kinda surprised to see a basic game from you.

I don't know what came over me.
When I analysed the ATAT game a while back I got a hankering for some BASIC coding.

The latest version is written in C and compiled with cc65 - that's why it doesn't fit on an unexpanded machine.

tokra · Post by **tokra** » Mon Jul 02, 2012 4:55 pm

Kweepa wrote:The latest version is written in C and compiled with cc65 - that's why it doesn't fit on an unexpanded machine.

Neat! How much faster compared to pure 6502-assembler would you say coding in C is and how much overhead do you assume you have memory wise compared to assembler?

Kweepa · Post by **Kweepa** » Tue Jul 03, 2012 5:00 pm

Tricky questions to answer.

For me, I'd say C coding is about 5x-10x faster than assembly, but oddly, based on this exercise, about half the speed of BASIC coding! Also, I didn't implement some things because the original implementation used floats and cc65 doesn't support them "natively".

As far as execution speed goes, that's the hardest question to answer (and I know you didn't ask it

). You can probably get about half the speed of pure assembly with some effort, but generally about a quarter. It's still much, much faster than BASIC obviously.

The overhead is minimal - maybe a hundred bytes of startup code - if you avoid all library calls, like I did (no #includes!). There's an overall size multiplier though, about 2x, which is very hard to avoid. I'd say BASIC and assembler are much the same size.

Kweepa · Post by **Kweepa** » Fri Jul 06, 2012 10:01 am

Probably the final version uploaded.
I modified the screen format from 22x23 to 18x28. I also added a block type and a couple of powerups.