Steel Ball(s)

[rmartins]

After using 6 vacation days, and 4 weekend days (in a total of 10 days,sleeping less than 6 hours per day), dedicated to give a boost to Steel Ball completion, I'm afraid I will not be able to provide a playable version by 15 March.

I knew I started with some handy-caps:
- only found out about contest in mid August 2015
- had no previous solid experience with Z80 Assembly in particular
- was not aware that ZX CPU frequency limits were that severe.
- use no pre-packaged libs
- use direct assembly
- have a big goal ( Physics based game with almost full screen scrolling )

CPU limits, eat most of my time, that had to be dedicated to optimizations and refactoring lots of code.

Using Zeus was fun, and good for quick tests, but severely limited development, once I got about 20KB source code into ZX Memory.
Since early February, I switched to using Pasmo, which increased productivity and removed the memory limits I had (with Zeus).

Tracking some obscure bugs in assembly, takes ages, and sometimes, is a very silly thing, like deleting an instruction in editor, by mistake.
Sometime it's not a "bug" at all, but interference from an external source, like ROM interrupt screwing memory data because I used IY register.

I also had to implement a Music player (implemented 3 distinct versions), to understand the limitations, which took some valuable time, investigating and coding.
I would like to public thank UTZ for his feedback and composing music for it.

I also used lots of time, to make and improve graphics, which I hope will show the effort put into them.

All these things had to be learned and done, but all this extra efforts skewed my initial estimate for game completion of about 6 months, in part time.

I'll be sure to finish it, but not for tomorrow (15 March).
Most of all, I want to make a good game.

Have to get back to coding now

[Ivanzx]

Rui, the deadline will be most most likely extended, unless anybody states the opposite in the next hours, so If I were you I would start planning your game with 15 more days

I know you will manage

Thanks, mate!

[hikoki]

I was wondering if there will be some way to ease / speed up the process of coding in ASM. What about writing pieces of code in ZX Basic Boriel and trying to optimize the generated ASM by hand?
To see the ASM code the compiler generates, use the -A flag. Eg. zxb -A program.bas

[rmartins]

Mar 17, 2016 0:00:02 GMT hikoki said:

I was wondering if there will be some way to ease / speed up the process of coding in ASM. What about writing pieces of code in ZX Basic Boriel and trying to optimize the generated ASM by hand?
To see the ASM code the compiler generates, use the -A flag. Eg. zxb -A program.bas

One could do that, but soon limitations will pop-up, it's a fact of life.

A very simple example: I'm using 24 bit values for some physics calculations, which is not commonly supported, specially when it's 16 bit for integer part, and 8 bits for fractional part (Fixed Point math).

Another simple example: Compilers usually don't generate self-modifying code, to speed it up.

Coding in ASM, takes a bit more time, specially on complex algorithms or strange calc situations and similar stuff. And it's unforgiving for any kind of bugs.

But ASM, empowers the developer to really get all the juice out of the machine, as I expect to demonstrate

[hikoki]

One feature of zx basic you may not know about is the tag asm which allows to enclose your own asm code, so you can mix basic with functions containing just asm, this kind of modularity and interaction may be useful to try different experiments in basic which are not critical on performance while other parts in asm are just kept encapsulated and even in communication with the basic outside.
Looking forward to see the game physics!

[rmartins]

Here is a visual update.



No time to explain details, but collision detection and reaction is working.

But now I need to refactor some code, due to game logic requirements

[Ivanzx]

Nice one!! You are almost there! Keep it up

[rmartins]

After another Marathon of 11 Days (6 more vacation days), I have the game about 90%.
Since I have a family trip, and a plane to catch in one hour, I can't finish it until 30 March.

However, I'm releasing the game in current Alfa version, for the contest.
It was a BIG patch work, to join all the parts tonight, so that it could be release as is.

It does not have a lot of stuff that was initially programmed, and that I still want to include, but it's playable, although game level length is limited by my lack of time and some game play features which are not ready yet.

What's missing

- Credits are empty, not enough time, to finish it.
- No scroll animation between Credits and Menu, as was initially defined
- Menus animate, but don't have any functionality (Press SPACE, to progress to game)
- Joysticks drivers are implemented and tested, but there is no way to select them, (except using POKE

- Score counter, is not working, so left it at 0000
- A few of the game play items are not yet implemented, but some can be seen
- Menu Music is missing

What's in

- Some BUGS (graphical and others), but most are know (for example, no time to implement the reverse clipped colored blit routine)
- Physics are working (but as one or two known odd behaviours)
- Respawn works, but sometimes bombs the sprite
- Almost all visible elements work as expected.
- SFX, for each item (some are not yet final, or might not be correct)
- Challenging fun and some frustration


Music is my worst sin, since UTZ provided it, but I just couldn't find time to integrate my player with menu animation, or even finish the menus for that matter


Enjoy, until I can provide a final version.

SteelBall ALFA

I'll be off-grid around a week, so don't expect quick replies

Now I have a plane to catch


TIPS:
Use O,P to move
A to affect the view.

(Q does nothing now).

[PROSM]

I am stunned, Rui. This game pushes the ZX Spectrum to its very limits! Even in its current state, it is extremely playable and responsive. You've certainly raised the bar for excellence in all areas. I look forward to the final version.

[RuiMartins]

Mar 29, 2016 7:08:50 GMT PROSM said:

I am stunned, Rui. This game pushes the ZX Spectrum to its very limits! Even in its current state, it is extremely playable and responsive. You've certainly raised the bar for excellence in all areas. I look forward to the final version.

Got some free wifi, while waiting for my connect flight.

Thank you for your kind words PROSM.

Currently games runs at 50 frames, except when scrolling, which drops to 25. This is a compromise, which makes the A key very useful

[rmartins]

I'm back.

Just noticed that ALFA version still has a DEBUG key enabled, which allows the user to make the ball jump higher, without limits, which is required to debug levels.

Please don't use this key, since game play is not designed for it, and will loose it's "magic" if you do.

By "magic" I mean the fact that physics momentum/velocity/height attainable is conserved (partially, since bounce elasticity is less than 1.0), which means that after a few bounces, we loose bouncing height and eventually revert back to a minimum bounce height, after a few bounces.

This is a required physical feature to solve some of the puzzles, i.e. keeping your momentum when reaching the desired location.


NOTICE:
There is a bug that surfaces sometimes, after Respawn, that makes ball invisible.
Pressing the fire key, will clear the problem, making the ball visible again.
If you ever need to use this hack, while playing, then wait for minimum bounce height, and proceed as normal.

For those that can't control yourselves and keep using the fire key (cheaters , you can use this updated version instead SteelBall-ALFA_no_fire.tap
NOTE: The only change, is to disable the fire key effect, by introducing NOPs.

[rmartins]

It didn't occur to me, when posting game ALFA version, to also post the music separately, since it was not integrated yet, but here it is SteelBall Menu Music by UTZ, running on my own player (V3)

NOTE: The Border color, is for debug, so that Speaker out can be somewhat debugged visually.

Once again, thank you UTZ, for your constructive feedback and producing music for my first 3 music players

[rmartins]

Due to some questions I got on how to play, besides the obvious, I believe it's better to make a small set of instructions.


1 - Keys are Q,A and O,P.
NOTE: For Joysticks [CURSOR,SINCLAIR1,SINCLAIR2,KEMPSTON], I can provide POKES if required.

Q and A control window panning, left and right.
NOTE: Q is not working, due to some last minute bug I introduced.


O and P, accelerate ball LEFT or RIGHT.

By accelerate, I mean you can also break (reduce speed), without reversing direction, if you are fast on keys.
Too much break and you reverse your direction.


User input (keys) is checked on every frame (50 times per second).

So if you press a key for a few frames, it will start to increase your speed fast.
Too much speed, implies that it's harder to stop too, since you have momentum, i.e. you have to counter act your "inercia".

Ball always accelerates down, due to gravity.

Ball breaks (reduces speed) a little horizontally, when no key is pressed (think of it like wind drag).


Resuming, for better control, give short inputs, instead of long key presses.


2 - Gaining height, can be done by bouncing off on higher platforms.
There is always a minimum bounce height on a platform. This is what enables you to go higher.

Bounce Momentum is kept but is slowly lost!


TIP: If you jump from a high platform into a lower one, the first few bounces, will take you almost as high, but it will gradually fade until you reach a minimum bounce height, if you keep bouncing in the same lower platform.


3 - There are special platforms (bright white) that work like Save Points (first platform is an example), but you have to touch them to save a new re-spawn position.

When a Save Point platform saves, it outputs a different sound on touch.
If you touch the same Save Point repeatedly, it will only sound different on first touch.

You can always re-save on a previous Save Point, if you changed to another Save Point meanwhile.
In some situations in the future it will be useful, when some backward movement will be required.

NOTE: First Save Point is defined as the first platform at start, so it won't sound different, unless you saved on another Save Point and then returned back to it.


4 - Generators, produce energy for other items (one or more), when ON.
Generators, can be enabled/disabled by a switch (on them or somewhere else).
Generators are typically color coded (RED, GREEN, BLUE), but don't trust everything you see


5 - Batteries, have energy for other items (similar to generators), but they don't produce energy, they are just batteries.
Batteries can be charged or discharged.
There are Positive (RED) and Negative (CYAN) batteries.


6 - Some items are controlled by a timer.


7 - Dangers

Falling off, will "kill" you.

Generators will "kill" you, if you touch the core/rotor, while ON.

Electrodes and electric ZAP will "kill" you, while ON.

Laser beam will "kill" you, while ON. (temporary)

Power Beam will "kill" you, while ON. (temporary)


8 - When you are "killed", you are sent back to your last Save Point.
So when you see one, make sure you touch it, to save your progress.


9 - DNA and Cube are special items.


Hope this helps.


WARNING:
There is a bug when you bounce near a platform EDGE, so avoid this situation.
Technical details: it happens when ball has high ABS( XVelocity ) and low ABS( YVelocity ), or in other words when ball has fast lateral movement and low vertical movement. It will bounce of in the wrong direction.

[rmartins]

Fix for panning issue.
The B register was being trashed after detecting the Q key action, hence A key action was being processed too, so no panning occurred, because they were cancelling each other out.

So, panning is back to normal now, using keys QA.

SteelBall-ALFA_FIX1.tap

[rmartins]

Now that the voting is over, and I had some time off from assembly language, I'll get back to it, to finish it as planned.