The dot

[sometimes99er]

Well, while the size of the assembler object code is minimal, it can be fun playing around and experiment from XB.



XB program (dot) and object code (doto) for Classic99 and assembler source (dot.a99) for Asm994a included in attached zip.

Edited February 1, 2014 by sometimes99er

[Opry99er]

Reminds me of a game on Video Brain called "Ant Farm" or some such thing. Very cool.

Edited December 10, 2010 by Opry99er

[unhuman]

Seems like Pac-Man type games could be written easily with this.

[sometimes99er]

Thanks for feedback.

It were of course only for testing purposes, that I was putting a character, 8x8 black block, to the screen. I could then "easily" verify, that the pixel to screen character location calculations were indeed pixel perfect.

There are/were no boundary check, so you could mess up (get nice and/or bad effects) in the first K within VDP - colors and sprite list are located there.

I've made sure that the dot only moves horizontal or vertically - hence you can't move diagonally. I'll change that later.



So what's happening now. Well, the machine language subprogram takes over, and once you start moving, there is no stopping. When you crash, control is returned to XB.

Edited February 1, 2014 by sometimes99er

[Opry99er]

That looks fantastic!!

[unhuman]

Now - with some inertia - I'm thinking Gravitar!

[sometimes99er]

I never heard of Gravitar. The screenshots for the 2600 looks colorful. Relatively long manual. Yes, assuming some gravity in there. Took it for a spin. Nice. Read a few reviews. The original arcade vector game looks cool.

 

http://www.youtube.com/watch?v=gfC76dHogH4

 

I guess there's some similarity with the reactor core. My plan was definitely to add some thrust system, maybe friction, and gravity is also a possibility - this might evolve into quite different games. To go beyond the dot.

 

Edited December 11, 2010 by sometimes99er

[sometimes99er]

Deleted a few lines of assembler. The dot now stops if you're not pushing the joystick in any direction. Much of the challenge (bringing the dot around) has gone, though more narrow alleys would now be possible. Oh, and you can now move diagonally - which appears to be double speed. Just a transition.

 

Anyways, if you didn't know, the machine language subprogram takes over, and moves the dot until you hit a wall. Movement and collision detection are on/sync'd with the frame update, so it's basically razorsharp (seems like Win994a and MESS moves the dot delightfully smooth when all settings are at 60Hz or multiples thereof).

 

Edited December 22, 2010 by sometimes99er

[sometimes99er]

Happy New Year !

 

This time I wanted to implement thrusters for movement.

 

Lunar Lander has like small thrusters for changing direction and one big thruster for forward movement. Lunar Lander also has gravity. We can't use anything like this for our dot, since we can't see what direction the dot is pointing.

 

Well, we simply do not allow our dot to rotate, and add one thruster for each of the switches in the joystick (often corresponding to the arrow keys in emulation). No friction or gravity. Simply free floating in space. Pull in the direction you want to move.

 

Turning corners is relatively hard. You have to counter thrust (brake) in the direction of movement to slow down and enable thrust to the new direction. Takes a little practice. Applying a bit of friction would maybe work miracles.

 

It does seem impossible (I should probably do the calculations !?), but if movement per frame was to exceed 8 pixels, one could actually "jump" the walls (the width of a character is 8 pixels).

 

Maybe adding holes (black holes ?) (Labyrinth) to avoid. Then changing the walls to be more like barriers in the collision detection. And perhaps adding a timer.