Hi, this thread will be used to present my entry to the contest.
Provisional name is "Steel Ball" or Balls
This will be a dexterity physics oriented game, in the current mobile entertainment way, few keys to control. You control a metallic (steel) ball, and jump around and do crazy stunts to progress further in each level, in a typical horizontal side scroller way, with some twists.
This will be my first game for ZX Spectrum, made completely in Assembly.
I haven't programmed a ZX spectrum since the 80's, hence this will be a fun exercise.
I'm doing this for the sake of fun and enlightenment, hence I'm using an assembler from 80's (Zeus), so that I can experience the work flows of the 80's. It has been nice so far.
I have a few routines already working and a ball bouncing up and down. I also have drawn some graphics, to research the mood of the game.
I'm building all routines from scratch: blit, sprite, scroll, etc...
Sound is the only thing I will probably use something already done in terms of code.
I also am willing to have a co-developer for making music or SFX.
Welcome again, rmartins! Wow, that sounds like quite a Project! Interesting theme there, and again, something not very often seen in the Spectrum. Happy to see that you are refreshing your skills and learning more at the same time you are coding the game, that is one of the purposes of the compo Maybe somebody could help you out with the music/FX. Perhaps asking in WoS would help you to find that person, as there is a lot of musicians over there. Looking forward to seeing those screenshots!
Bienvenido de nuevo, rmartins! La verdad que parece que el proyecto va bastante viento en popa! Y además, de nuevo, es un tipo de juego no muy común en el Spectrum de nuestros días! La verdad que me parece genial que estés desempolvando tus conocimientos de programacion en código máquina para el Spectrum, al mismo tiempo que aprendes. Esa era una de las razones por las que se creó este concurso Sí que estaría bien si alguien pudiera ayudarte con la música o efectos de sonido. Quizás en WoS, ya que hay muchos músicos en los foros, puedas encontrar a alguien. Esperando a ver esas pantallas!
A very important factor when programming to the metal is timing and synchronization.
Here I'm using border color as a useful visual aid to debug my rendering time.
From looking at the picture it's clear that I'm finishing drawing too late, since ball is only partially visible, and in some frames it doesn't even show, since it depends directly from current ball vertical position. If it goes below the timing where ULA scan is, it will only show in next frame, since it isn't there yet for ULA to see when scanning.
NOTE: I'm doing a full screen clear, some calcs and blitting some stuff to the screen. Border color (blue and red), shows that some part of the drawing code, is running after ULA finished scanning screen pixel area.
Even doing crazy stunts in assembly to fill the screen as fast as possible (using fastest instructions, by stack push to write to screen), it is clear to me now, that it's impossible to sustain 50hz frames by redrawing the entire screen.
There is a remote possibility of it being remotely possible or approachable, but very hard to accomplish, since my code inside Zeus is running (0x6000) in contended memory (anything between 0x4000 and 0x8000), which is slower than if code was running in NON-contended memory (above 0x8000 or below 0x4000, in ROM area, by making a Cartridge for example).
I haven't test my code running in NON-contended memory yet, which could prove a huge boost, but I'm note sure. Something I will test further along the way.
This knowledge (not enough performance for full screen rendering) implies some adjustments how I will code the game and might impose some restrictions on what can actually be done.
P.S. Zeus has a version for 16K Spectrums too, which will reside in content memory, eventually allowing me to place my code in non-contended memory above 16K. But I haven't tested if Zeus miss behaves in this condition, since by default it assumes code and symbol table will be below it's current memory position, since it does some checking to warn user in case of near overwrite of symbol table or Zeus code.
If it miss behaves, another possibility could be to move Zeus 48K version into lower memory, but that would probably require a refactoring on fixed jump and CALL target address.