Ah yes, I initialise memory to $CE in my emulator... I'm guessing vice might zero it.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.
New Release: KWEEPOUT
Moderator: Moderators
-
- The Most Noble Order of Denial
- Posts: 343
- Joined: Fri May 01, 2009 4:44 pm
- Kweepa
- Vic 20 Scientist
- Posts: 1315
- Joined: Fri Jan 04, 2008 5:11 pm
- Location: Austin, Texas
- Occupation: Game maker
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? )
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?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? )
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
- Vic 20 Scientist
- Posts: 1315
- Joined: Fri Jan 04, 2008 5:11 pm
- Location: Austin, Texas
- Occupation: Game maker
To uudecode some strings into UDGs:
(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...
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
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
- Vic 20 Scientist
- Posts: 1315
- Joined: Fri Jan 04, 2008 5:11 pm
- Location: Austin, Texas
- Occupation: Game maker
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.
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.
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.
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
- Vic 20 Scientist
- Posts: 1315
- Joined: Fri Jan 04, 2008 5:11 pm
- Location: Austin, Texas
- Occupation: Game maker
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)
(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)
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!
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
- Vic 20 Scientist
- Posts: 1315
- Joined: Fri Jan 04, 2008 5:11 pm
- Location: Austin, Texas
- Occupation: Game maker
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.
http://www.kweepa.org/step/vic20/kweepoutmc.prg
I didn't do the smooth movement - I'll probably leave it as is.
Last edited by Kweepa on Sat Mar 16, 2019 9:46 am, edited 1 time in total.
-
- The Most Noble Order of Denial
- Posts: 343
- Joined: Fri May 01, 2009 4:44 pm
- Kweepa
- Vic 20 Scientist
- Posts: 1315
- Joined: Fri Jan 04, 2008 5:11 pm
- Location: Austin, Texas
- Occupation: Game maker
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.
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.