WIP: Fleas

Discussion, Reviews & High-scores

Moderator: Moderators

Post Reply
IsaacKuo
Vic 20 Hobbyist
Posts: 147
Joined: Tue Aug 04, 2009 5:45 am

WIP: Fleas

Post by IsaacKuo »

Not really a WIP yet...I'm only a few lines in. I just figured starting a WIP thread would help me hammer down some ideas and with motivation. It's my first assembler project.

Fleas is like Lemmings, except Fleas are just a single pixel. Each game cycle, one Flea makes a "jump". A jump is an arcing path that travels between 6-8 pixels across. The jump travels upward by 5 pixels and may fall downward by any amount. If the Flea collides with an obstacle during the horizontal leg, he bounces off an reverses direction.

Code: Select all

..****..
.*....*.
*......*
*......*
*......*
*......*
The player controls a "crane" at the top of the screen, capable of dropping a limited supply of obstacles.

To make level design easy, I've decided to use unreversed PETSKII for the levels. This lets me use 7168-7679 for custom graphics characters while using ROM characters also. The file format for a series of levels is simply a series of strings (up to 255 characters long). At the start of each level, the program simply prints {clr home}{rvs}{wht} and then prints the level string. Thus, you get full color capability along with some simple compression. The program then checks for reserved characters for the "start" and "destination".

The top left of the screen shows the available user obstacles and how many of each are available (from 1 to 9). Each obstacle is represented by a PETSKII character, so the level may start off with some obstacles in place already.

The second line is where the player's "crane" is. The controls are simply:

J/L - move left/right
K/I - switch object
space - drop object

Now, I need ideas for the obstacles. So far, I'm thinking:

lava/water (C= lb) - simply kills a Flea

bomb (club, or shift-X) - detonates on contact with a Flea, erasing the four neighboring chars along with itself

trampoline (=) - instead of landing on it, a Flea will rebound upward into a 16 pixel high jump.

diagonal ramps (shift-N and shift-M) - not treated differently from any other character, but they're useful for guiding Fleas upward.

walls (shift- -) - not treated differently from any other character, but they're useful for reversing the direction of Fleas.

Any other/better ideas for obstacles?

Thanks!

- - - - -

I've chosen "Fleas" as my first assembly project because it's pretty easy in a lot of ways. I don't have to design sprite graphics or animation, and I don't have to worry about simultaneously moving multiple sprites. Just one Flea moves at a time, and since a Flea is only 1 pixel big I can reserve 62 custom chars for up to 62 Fleas on screen.

The use of PETSKII graphics greatly simplifies level design effort, and I like how it gives a distinctive VIC20 "look and feel". Also, the level design system is essentially identical to my old animation program. It's merely character by character keyboard input, along with a "cursor drawing" routine.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Even if your current plan devises to use a sprite-ish implementation with a dynamic pool of user defined characters - have you thought about using MINIGRAFIK for a test implementation (click here for an example *.d64 disk image)?

Your fleas are single pixels, and single pixels are, what MINIGRAFIK ultimately manipulates. You can use line commands to draw the level shapes, and there's a function included to test whether a pixel is set, or clear (it returns the logical colour of a pixel).

I'm not talking about speed. This test implementation will be slow since it's still written in a slightly enhanced BASIC - but it can give you a good idea later, how to implement it in machine language.

Michael
Last edited by Mike on Sun Aug 31, 2014 1:07 pm, edited 2 times in total.
IsaacKuo
Vic 20 Hobbyist
Posts: 147
Joined: Tue Aug 04, 2009 5:45 am

Post by IsaacKuo »

MINIGRAFIK would be awesome, and it would be fast enough since there's only one pixel moving on the screen at a time.

I somehow had the impression (perhaps wrong) that it requires at least 8K to run. That's why I hadn't looked further into MINGRAFIK. But thinking about it--it's not like I'm limited to 3.5K if I'm only developing on an emulator.

In any case, coding in 6502 assembly is really exciting for me. You know the thrill of programming in a new computer language, right? Doing the same old boring POKEs and PEEKs is somehow fresh and new in a new language. So, at the moment I'm not in the mood for BASIC coding.

Keeping in mind the limitations of stock RAM, I'm thinking of putting together some simplified routines less ambitious than MINIGRAFIK. No BASIC integration--just ML subroutines--and all they do is RESET or SET a pixel. I'll be using this for some of pixel based games later on. My basic idea is:

SET routine--checks to see if there's already a custom character in the desired location; if not, it places an unused custom character there (clearing out a used one if necessary).

RESET routine--erases the dot; if the result is zero then it checks to see if the other 7 lines are also zero; if so then the character is cleared out and added to the list of free characters.

TEST routine--checks for a collision with an existing pixel.

These routines aren't meant for generic bitmap graphics, but rather tailored for either sparse graphs or pixel based "worm" graphics. By "worm" graphics, I mean graphics like the "worms" screensaver. A "worm" is rendered with a SET on its "head" and a RESET on its "tail". This sort of thing is used for Missile Command. My space wargame idea will use this sort of graphics rather than sprite bitmaps (they consume a scary amount of space, with all the rotations and especially with pre-rolled bitmaps).
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

IsaacKuo wrote:I somehow had the impression (perhaps wrong) that it requires at least 8K to run.
You're right. MINIGRAFIK requires at least an 8K RAM expansion.

I developed this BASIC extension only within VICE, as at that time my hardware setup only consisted of an VIC-20 with a 3K RAM expander. This didn't keep me from doing it anyway.

If MINIGRAFIK provides an easy implementation path for you, why not go for it? Even if you'd need a RAM expander, you can get one. And software-wise, there's something already implemented available for use. Set, reset, and test are: '@1,X,Y', '@0,X,Y', and '@(X,Y)', respectively.
IsaacKuo
Vic 20 Hobbyist
Posts: 147
Joined: Tue Aug 04, 2009 5:45 am

Post by IsaacKuo »

Mike wrote:If MINIGRAFIK provides an easy implementation path for you, why not go for it?
At the moment, it's just my current mood.

I'm having fun assembly coding, so I don't feel like breaking my momentum and coding in BASIC. I'm currently more motivated to code/learn 6502 assembly. I know it's all old boring stuff to you guys, but it's new to me.

Besides, it's not like I'm a wizard at BASIC coding to begin with.
IsaacKuo
Vic 20 Hobbyist
Posts: 147
Joined: Tue Aug 04, 2009 5:45 am

Post by IsaacKuo »

update:

I bit off more than I knew with my plan to use dynamically allocated character graphics. I had to write it in order to realize how complex the task would be.

I've now written code for dynamically allocated TESTXY, SETXY, and RESETXY; it's not yet fully debugged. It conceptually uses 3 65byte arrays to store:

FLEAPOP : flea population of each custom char
UNDERCHAR : the PETSCII char underneath the custom char
FREELIST : a linked list stack of free chars

To save memory, FLEAPOP and FREELIST actually overlap. The flea population only matters for on-screen custom chars; the list of free chars never includes on-screen chars.

I didn't have a good idea of how I was going to handle tracking or searching for free chars. The linked list stack just naturally evolved from what would be easiest to implement.
IsaacKuo
Vic 20 Hobbyist
Posts: 147
Joined: Tue Aug 04, 2009 5:45 am

Post by IsaacKuo »

IsaacKuo wrote:...it's not yet fully debugged...
I should have said "tested", rather than "debugged". I've been testing my code, and I actually haven't unearthed a single bug yet. Given the sheer amount of stuff going on with bit twiddling, linked list manipulation, table lookups, and such...pretty hard to believe!

So, I'm confident about the dynamic bitmap portion of the code. Next step is building/maintaining the list of flea X/Y coordinates--a piece of cake compared to dynamic custom character allocation.

268 lines in; 302 bytes so far...
Post Reply