Jump to content
IGNORED

Rastignac's 2600 homebrew: "LEM" (aka Lemmings Killings?)


Rastignac

Recommended Posts

My first 2600 homebrew, project "F40", is still unfinished: https://atariage.com/forums/topic/179464-my-2600-racing-game-f40-aka-ferreira-40-kb/

My second 2600 homebrew is just started now: project "LEM".

 

** About the Project "LEM":

* The goals of the project are:

- Pure asm.

- 4KB limitation.

- HD graphics (1LK: one line kernel).

- Many many sprites on screen.

- Multicolored sprites.

- Many frames of animation per sprite (detailed walk animation, etc).

- Support for 60hz Ntsc, 60hz Pal/Secam, 50hz Pal/Secam.

- Control: joystick.

- Single player.

- ("Two players cooperation" or "two players competition" may be an idea for later).

 

* First Prototype status (v0.0.0a):

- This prototype is unfinished, but it could become potentially interesting.

- No title screen, no menu, not even a real name or title for the project yet.

- No gameplay yet; prototype is not interactive.

- No sound, no music.

- Only Ntsc is handled now. The "Select" switch will be used to cycle through Ntsc60/PalSecam60/PalSecam50 (like "F40" does).

- Untested on real hardware. It may suck on a real CRT/LCD TV set. It may bug on a real console.

- Graphics and colors are unfinished placeholders. They can be far better.

- Sources are not available yet, because they're so ugly. Sources will be available later.

- Line count seems stable, and bad, but nearly good.

 

* Initial ideas (pre-v0.0.0a):

- It's a very old concept (several years old idea).

- One screen; no scrolling; nine lanes.

- Each lane has a turret. Turret is hanging from the ceiling.

- Badguys/monsters run toward the turret. They win if they manage to exit the screen.

- The turret can fire a laser/missile (one at a time, with a "cool down timer" after each shot).

- Joystick selects a turret; holding a direction highlights the selected turret; fire button fires the chosen turret.

 

* Badguys (pre-v0.0.0a):

- They are 20 pixels tall (HD pixels are half square pixels).

- One 256-bytes page can hold 12 sprites.

- Now, only four temporary placeholder sprites are drawn; they are used as a walk animation. It could be enhanced (six or eight frames for the walk animation; death or victory animations; two or three different types of badguys; etc).

- They are multicolored (20 different colors per sprite: one color per line).

- Now, there is only one palette for all the sprites. The way sprites are drawn makes sure they all share the same colors (head is always drawn at the same lines; etc). It gains space (less rom) and speed (less cpu).

- Walk speed can be changed (slow and easy, then faster, then faster, the game being harder and harder).

- Badguys could be monsters, zombies, aliens, soldiers, knights, trolls, or whatever creatures walking relentlessly and inexorably.

- They look like walking Lemmings. Yeah, the nice and lovely (and stupid) Lemmings. So, let's kill Lemmings!

- Amiga's Lemmings are ten pixels tall, with three colors (blue, white, green). Mine are 20 (half-)pixels tall, with 20 colors.

- A lane can have from zero to six badguys; many configurations are possible (ababab, aaa bbb, a a a b b b, etc).

 

** Changelog/evolution of the project (pre-v0.0.0a):

* There were nine lanes

- Pressing "up" selects the first lane; it has a center turret; badguys come from left and right of the screen.

- Pressing "left+up" selects the second lane; it has a left turret; bad guys come from the right of the screen.

- Pressing "right+up" selects the third lane; it has a right turret; bad guys come from the left of the screen.

- Pressing "left" selects the fourth lane; it has a left turret; bad guys come from the right of the screen.

- Centering joystick selects the fifth lane; it has a center turret; etc.

- Pressing "right" selects the fifth lane; it has a right turret; bad guys come from the left of the screen.

- Etc, etc.

- Then center lane was removed. Game now has a neutral position. Centering joystick selects nothing.

- Center lane can be used to display score/lives/timer/title, etc.

- Eight lanes remain.

- Center turrets are a problem: two ways to shot can't be easily handled now.

- Six lanes remain.

- Joystick control is better: three on the left, three on the right, that's clear.

 

* There were turrets

- Turrets are suspended from the ceiling, so they don't share lines with the sprites on the ground.

- Turrets can fire lasers.

- Lasers can be drawn with PF graphics. It needs a "diagonal drawing" routine, or some pre-computed tables for every possible lines of fire.

- Removing turrets is better. Gain of lines. No more diagonal.

- Lasers are replaced by a rocket/missile.

- Rocket/missile can be drawn with the "ball" (a four pixels wide one seems fine).

- A fast way to draw "ball" is to use a 20-bytes table with "0,0,0,0,0,0,0,0,2,2,2,2,0,0,0,0,0,0,0,0".

- Rocket/missile is a lame/stupid square/rectangle/brick. That's ugly. It can be much better.

- Changing "ball" size (1/2/4/8) every line is possible. A nice object can be drawn by changing "ball" size every line and fine-moving it every line, to make a shape appear.

- Then a nice rocket is done, and it looks great.

- Twenty lines are enough to draw two rockets. That's more menacing.

- Problem is parasite pixels: "ball" is enabled during all of the 20 lines, so it is not hidden before/between/after the rockets.

- Then, let's use parasite pixels: by moving them farther, they now look as smoke/trail of the rockets.

 

* Cpu, limits, cycles, optimizations

- Now, only six lanes can be drawn during a frame. It's the bottom limit (less than six would suck); but eight or nine could perhaps be better.

- Now, there's no room on screen for scores/lives/etc.

- Sprites and palette must be copied and cached from rom to pagezero ram. But memcopy eats too many cpu cycles. It can't be optimized more?

- Cache in pagezero already eats 60 bytes. All sprites can't be copied there. Or sprites must be smaller. Not wanted.

- Horizontal positions eat many cycles. Three objects per lane need to be placed. They can't be optimized? I think it can be optimized.

- Now sprites are autonomous. Lane can be "ababab" but also "aaa bbb" or "b b b a a a" or others, and that's good. A way to gain cycles is to always glue sprites together (ie: "ababab" and only this configuration). The two sprites can be positioned in one pass (the second being slave of the first). Not wanted.

- A way to improve cycles is to reduce animations. Not wanted. Now lanes can be "ababab / acacac / dbdbdb / aeaeae / etc" and that's great. Dropping to "ababab / ababab / ababab / etc" is lame. The "army of clones/robots" effect must be avoided.

- Rom space seems not a problem. There's room for more graphics, for title screen, for music and sounds, etc.

- Ram space is a bit short, but it's enough now. It must be watched.

- Computations for the six lanes can become costly. But it can be optimized: badguys don't walk 60 times per second. So, it's possible to skip some lanes, and only refresh one or two lanes at each frame. Rockets should be refreshed at each frame, for smooth and fast firing.

** Changelog/evolution of v0.0.1a:

* v0.0.1a

- Clever code, with VDEL. It frees ram (less needed cache), it frees cputime (less needed cache filling).

- Optimized horizontal positions. It frees cputime.

- Main kernel is closer to final.

- Pseudo dirty random generator added, for non-interactive demo (prototype plays by itself).

- Collisions' detections begin to appear. Gameplay begins to show.

- Still no real name/title for the project.

** Changelog/evolution of v0.0.2a:

* v0.0.2a

- Killing now works. Beasts die. Joy.

- Killed animals pop back. (Not finished yet; better progressive visual effect to come later; poptime will come later).

- Killed lemmings are randomly resurected. (they pop back by one, two or three; three is 50% luck, one or two is 25% luck).

- Ram saving is the target. One less variable is six bytes less (because six lanes). Three variables saved = 18 bytes free.

- Still not a game. Not interactive yet. Prototype still plays by itself.

- Still no real name/title.

- Still no sound. Still no music.

- Still no public sources.

** Changelog/evolution of v0.0.3a:

* v0.0.3a

- More animations! (Lemmings being shot)

- Code cleaned. Macros! Optimizations! Deduplications!

- Source code is now available. Read! Learn!

- Still not a game. Not interactive yet. Prototype still plays by itself.

- Still no real name/title.

- Still no sound. Still no music.

- I think I uploaded a wrong version (kind of v0.0.2.9a). Sorry.

** Changelog/evolution of v0.0.4a:

* v0.0.4a

- It's the bugfixed v0.0.3a. Previous v0.0.3a was the wrong files.

- Named v0.0.4a, so it's more clear.

** Changelog/evolution of v0.0.5a:

* v0.0.5a

- Removed stupid "sprites cache" code. A lot of ram and cpu gains!

- The "BadGuys can win" routine is here. They win a lane if they manage to touch the rocket before it's fired.

- BadGuys dance together when they win a lane. (Graphics and animations are placeholders).

 

* Future versions:

- A lot of things must be done now. Stay tuned.

- Interactive gameplay will come in next version.

Thanks.

 

PS: it's better "in motion" than "in screenshots". It's a nice screensaver too.

LEMv005a.bin

LEMv005a_src.zip

Edited by Rastignac
  • Like 3
Link to comment
Share on other sites

Although they probably not jump off cliffs when they get too many (and that supposedly is a hoax or misunderstanding anyway), they have a great group hierarchy and seem to allocate different tasks to different individuals within the group.

 

Who? The Meerkats!

 

Also, an alternative name and slightly changed graphics would also steer you clear from any future trademark breaches, in particular if you finish it into a commercial release.

 

Just a suggestion.

 

Edit: Sorry, didn't read closely enough. I thought those were the good guys, but if they're the bad ones to get rid of, I suppose the good old zombies, vampires, aliens etc are better candidates than cute and intelligent animals. Perhaps there are more annoying animals, like moles, voles or slugs you would put there. Then again down under, even such cute animals as koalas have become so many in parts of Australia that they need to kill of a number of them to keep the population sustainable, and if they can kill koalas in real life, you could kill just about anything in a video game.

Edited by carlsson
Link to comment
Share on other sites

  • 2 weeks later...

v0.0.1a should come in a few days. It should be "less prototype" and "closer to real game".

 

With a little optimization, I went from 266 lines to 251.

Three objects per lane took six lines for generic horizontal position; now it's only three lines.

So, it makes 3 lines gain for five lanes (first one was already optimized).

Gain enables enough free cpu to add many things (collisions' detection, cooldown timers, etc).

 

Then, I'll need a random generator, and joystick reading, and the core will be ready.

 

(Also, I should use "VDELBL", but I still can't figure out how it really works; it just doesn't work the way I think it should work).

 

(I still didn't have find a real/proper title/name for the project yet).

 

Thanks.

Link to comment
Share on other sites

Then, I'll need a random generator, and joystick reading, and the core will be ready.

 

(Also, I should use "VDELBL", but I still can't figure out how it really works; it just doesn't work the way I think it should work).

Have you seen my blog series Collect? It covers, in great detail, the development of a simple 2K game.

 

Step 4 covers VDELP0 and VDELP1 which work the same way that VDELBL does. Step 11 adds the ball object and uses VDELBL.

 

Step 10 covers random numbers.

 

Step 4 is also when I added joystick support. You'll have to download the source to see those routines. There's lots of comments that explain how the routines work.

 

If you have an questions, post them in the appropriate blog entry.

Link to comment
Share on other sites

v0.0.1a should come in a few days. It should be "less prototype" and "closer to real game".

- Collisions' detection are half-done. Gameplay begins to show.

- Quick and dirty pseudo-random generator is added. It should be better (more random) later. Gameplay begins to show (ie: prototype autoplays by itself) (still no joystick routine yet).

- Main kernel routine must be rewritten. It was smart. It needs to be smarter.

- Kernel eats 60 bytes of ram for cache (3x20). It's too much. It can be done with 40 bytes (2x20). Clever. Gain: 20 bytes, and some cpu time (less cache filling).

- I now use VDELP0/VDELP1, and it works fine. But VDELBL doesn't. Am I a dork? I don't understand. It should work the same way, shouldn't it? (Sources will be available soon, so perhaps someone will find my stupid bugs).

- I still don't have a proper title/name for the project. "Lemmings Killings" is the best I could find so far. Pffff.

- I found some strange things in Stella; I don't understand. It sometimes behaves strangely. Something is rotten with my computer, perhaps.

- I should think about music. DmaDesign/Psygnosis' Lemmings had fine tracks. (Public domain songs?). I should think about sounds. Digits? AtariVox?

- Progress is slow, but real. Stay tuned.

 

Thanks.

 

PS: @SpiceWare: your blog is great, your work is great.

Link to comment
Share on other sites

- I now use VDELP0/VDELP1, and it works fine. But VDELBL doesn't. Am I a dork? I don't understand. It should work the same way, shouldn't it? (Sources will be available soon, so perhaps someone will find my stupid bugs).

If VDELP0 is on, any updates to GRP0 are delayed until GRP1 is written to.

 

If VDELP1 is on, any updates to GRP1 are delayed until GRP0 is written to.

 

If VDELBL is on, any updates to ENABL are delayed until GRP1 is written to - so it works the same as VDELP0.

 

PS: @SpiceWare: your blog is great, your work is great.

Thanks! I've added the above as comments to Steps 4 & 11. Edited by SpiceWare
Link to comment
Share on other sites

If VDELBL is on, any updates to ENABL are delayed until GRP1 is written to - so it works the same as VDELP0.

I put #0 in ENABL, and so the ball is invisible; then, a few lines later, I put #1 in VDELBL, and the ball appears at once; it's not delayed, and that's my problem; as soon as I enable VDELBL, the ball switches to the visible state; it's because of the old/new registers pair system; I couldn't find a way so far; I'll look again later.

Thanks.

Link to comment
Share on other sites

I put #0 in ENABL, and so the ball is invisible; then, a few lines later, I put #1 in VDELBL, and the ball appears at once; it's not delayed, and that's my problem; as soon as I enable VDELBL, the ball switches to the visible state; it's because of the old/new registers pair system; I couldn't find a way so far; I'll look again later.

Thanks.

The GRPx and ENABL registers actually have a "shadow register" that comes into play. This bit in Collect's Vertical Sync might help:

 

        lda #0      ; LoaD Accumulator with 0 so D1=0
...
        sta GRP0    ; blanks player0 if VDELP0 was off
        sta GRP1    ; blanks player0 if VDELP0 was on, player1 if VDELP1 was off 
        sta GRP0    ; blanks                           player1 if VDELP1 was on
You might need to expand that to something like this:

        lda #0      ; LoaD Accumulator with 0 so D1=0
...
        sta GRP0    ; blanks player0 if VDELP0 was off
        sta ENABL   ; blanks                                                             ball if VDELBL was off
        sta GRP1    ; blanks player0 if VDELP0 was on, player1 if VDELP1 was off, blanks ball if VDELBL was on
        sta GRP0    ; blanks                           player1 if VDELP1 was on
Over at MiniDig on the tricks page you'll find a bit on VDEL Explained that might help you wrap your head around what's going on. Edited by SpiceWare
Link to comment
Share on other sites

Wow, I found the damn *typo*. Now it works. I was an idiot. Logic was good, typing was bad, eyes were worse.

So, I uploaded "v0.0.1a prototype". It's still a non-playable prototype, but it's closer to final target.

With VDELP0 and VDELBL, with clever code, it gains a lot of ram and cputime.

I now have enough ram to work with. I have enough cputime left (19 lines out of 192 are "free"; display is 262-lines stable) to add gameplay code.

Next version will be better.

 

Thanks.

 

Edit: a v0.0.1a screenshot.

post-17929-0-25492500-1428945128_thumb.png

Edited by Rastignac
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

v0.0.3a makes some progress.

Code is being cleaned. Sources will be readable.

Macros are being used for even cleaner code.

(Yeah, I now remember the little difference between "lda zp,x" and "lda zp,y"... Stupid... I should rewrite some code...).

Stay tuned.

Thanks.

  • Like 1
Link to comment
Share on other sites

Using two bytes of ram to remove about one page (256 bytes) of rom... Should I? Let's think... Yes!

Rom is now under 2KB. Game is not finished yet (it's far from finished) but rom size goes on the right way.

 

v0.0.3a seems to have no visible progress for players, but inside it will be much more clean. Code will be showable.

Link to comment
Share on other sites

v0.0.3a is now available.

Source code is also available.

See "what's new" in first post.

It's still a WIP, it's still a "screensaver", but it shows progress. (And code is clean).

 

PS: there are known bugs/problems. (Line count is 268; it should be 262) (the Lemmings' fine entrance is not yet done; they appears "at once" and not one by one) (etc) (I think I uploaded the wrong code!) (some code lines are missing) (oops) (v0.0.4a should fix all that)

 

PPS: I have another homebrew still in the shadow, but coming soon (as a v0.0.0a). Codename "BST". In a few weeks.

Edited by Rastignac
Link to comment
Share on other sites

Yesterday's v0.0.3a was the wrong files. Sorry. I took the wrong ones from the usbkey. I've seen that too late, after the uploading.

Today's v0.0.4a is the true v0.0.3a. Named v0.0.4a, so it's clearer.

 

(Fixes: number of lines should be good (262). Killed lemmings are the good ones.)

 

Thanks.

 

PS: the shadow project "BST" may eat my free time, so next "F40" and "LEM" versions may be late...

Link to comment
Share on other sites

Progress with v0.0.5a...

The whole "sprites' caches" idea looked fine a few weeks ago, but now it looks less fine... The previous "2x20 bytes for sprites' cache" became "1x20 bytes" (it saved a lot). Now, I removed all that. It saves again a lot of ram (20-2=18 bytes), and it saves a lot of cpu time!

Now I do have 28 free lines in my kernel. And a lot of free ram. Useful for later.

I also put the "BadGuys can win" routine in the code. If they touch the rocket (before being shot), they destroy it, and the said lane is won by them. And then, they dance!

Stay tuned.

Edited by Rastignac
Link to comment
Share on other sites

Here is v0.0.5a (bin and sources in first post; screenshot here).

Nice. Nicer.

 

PS: there are many things to add: sounds (samples?), musics, title, menu, score, joystick, etc. But the game's rough shape is already here.

PPS: I think I'll add 16bits computations in next version. I have enough free ram and cpu. Variable speed will add challenge and fun! (and 60hz/50hz will play at same speed).

PPPS: now I must also work on my other shadow project "BST"...

post-17929-0-43174800-1431541640_thumb.png

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...