|
Post by rmartins on Aug 26, 2015 20:31:43 GMT
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. Any one interested ? Composing music is not my strongest ability  Will post some pictures soon.
|
|
|
Post by Ivanzx on Aug 26, 2015 23:17:09 GMT
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!
|
|
|
Post by rmartins on Aug 27, 2015 9:51:32 GMT
Going back a bit, here is the first working sprite pixel blit to screen. Basic stuff. 
|
|
|
Post by rmartins on Aug 27, 2015 9:58:49 GMT
Some more progress, in bitmap handling, and first ball bitmap version. 
|
|
|
Post by rmartins on Aug 27, 2015 10:04:01 GMT
Keyboard Handling added. Used to control sprites/bitmaps position, and found first visual bugs 
|
|
|
Post by rmartins on Aug 27, 2015 10:15:21 GMT
Showing the dirty details of development, visual debugging 
|
|
|
Post by catweazle on Aug 27, 2015 10:48:56 GMT
Sounds very cool, and nice to see some development shots! 
|
|
|
Post by javiperez on Aug 27, 2015 11:52:17 GMT
Will you be programming with the Zeus assembler directly on the Spectrum???
|
|
|
Post by rmartins on Aug 27, 2015 11:57:46 GMT
A moving and bouncing ball on screen. The moving part you will just have to believe me  
|
|
|
Post by rmartins on Aug 27, 2015 11:59:39 GMT
Will you be programming with the Zeus assembler directly on the Spectrum??? Yes, I am. But for some development, screenshots and similar I'm using Zeus running on Zero emulator on a PC. I transfer stuff between systems, using a DivMMC interface.
|
|
|
Post by rmartins on Aug 27, 2015 12:28:09 GMT
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.
|
|
|
Post by rmartins on Aug 27, 2015 12:51:34 GMT
Here is a screenshot showing a huge improvement when using the crazy assembly stunts, but it's still not enough.  There is a lot more to add to the game, which will eat up some CPU, making this performance insufficient. There are some minor tweaks that I can still try, but I'm convinced it will not be enough. I still intend to make it scroll flawlessly horizontally, but I will have to make some hacks for the sake of visual performance.
|
|
|
Post by rmartins on Aug 27, 2015 16:44:34 GMT
Here is the first design prototype of the start level 
|
|
|
Post by Ivanzx on Aug 27, 2015 17:26:22 GMT
Looking really good! Keep the good job! Have you already found any musician??
|
|
|
Post by rmartins on Aug 27, 2015 18:00:52 GMT
Nope, not yet.
|
|