ParadigmShifter

In my code you mean? There's only 1 HALT in the mainloop. There's another halt just before I set the correct attributes for a level to try and avoid a bit of flicker when showing a level for the first time but I don't think it's 100% effective, maybe if I have 512 bytes to spare at that point I could work out the attributes (rather than having to go from collision tile to attribute value via a lookup table) to set them faster. There's also 2 HALT to delay the colour cycling of the Demo Over message. The Game Over sequence does drop a frame unfortunately (you can see the foot speed up a bit at the end when it starts not dropping a frame), but it's nowhere near as flickery/teary as the original version. It's generally a bad idea to remove HALT instructions if your game runs faster than 50fps 😉 It looks quite cool though. That was first thing I tried on day 1 of my first job (working on a PS1 game), I saw "WaitVBlank();" in the first example code I compiled and thought hmm waiting sounds bad what happens if I take it out? It was very very fast indeed then and left trails across the screen lol 😉

Details of how the font works is in this thread (although I made it draw to an offscreen buffer, in this case the collision map before it is cleared before starting a new level later on, which is how it does it in the code at present) https://spectrumcomputing.co.uk/forums/viewtopic.php?t=11743 8 and 9 high letters are a big hack, it just copies the 4th row of the glyph 2 or 3 times instead of having any extra data for the letter (which applies to (C), j and Q). Which works well with the font I made but may not work for all fonts. I will probably add a kerning adjustment special character at some point (I don't like the spacing between T and e in Telephones for starters).

You can update and then move if you do the wait for VBlank just before you start drawing as well of course. You may have to jump into the mainloop on the first frame then to avoid updating enemies on the first frame (original Manic Miner may do that - update guardian positions before it draws them for the first time anyway?) I know Matthew Smith just turned interrupts off and there is no HALT to sync with the raster in his code. That causes tearing and/or flicker if you do that though. I just do the draw first and I start with empty erase lists so it erases nothing it just draws the guardians without erasing anything. (It will redraw any cells Willy is standing in front of when doing the Willy erase though). The code is now public on Github anyway if you want to read it (or build it yourself - requires sjasmplus) https://github.com/ParadigmShifterRetro/SlickWilly

SWDEMO.TAP - Released! https://drive.google.com/file/d/1YWsWCc-D16ShxHXppiFXyqObCZXgTyi8/view Original Concept/Character Animations: Gabriele Amore Additional Animations: Lee Bee Eugene Sprite: HEXdidnt Final Barrier image: Grongy, with adjustments by Lee Bee Programming/Font: Paradigm Shifter AY music (by Lee Bee) also to be added at a later date. This is just a rolling demo, similar to the original attract mode, it just shows each level for a few seconds each. Engine is running at 50fps even while playing the tune on the 48K beeper. Willy will update at 50fps too. Enemies currently update at 25fps (but are being redrawn at 50fps). Willy movement and collision to be added next, and will do another release (with source code) once the levels are playable. All feedback is welcome. See also this thread: https://spectrumcomputing.co.uk/forums/viewtopic.php?f=7&t=11662 I'm also looking for tile designers, level designers etc. Post in the thread or PM me if you would like to contribute. swdemo.tap

Crucial point is that I do a HALT and then immediately start erasing and drawing everything (to beat the raster - hopefully - I can make it flicker a tiny bit if I give it a really bad case for the solar power beam at the moment but I have some speedups for the beam drawing up my sleeve still). Once everything is drawn I work out what needs to be erased next frame, I set up all the guardian screen addresses of where they are now at, I work out the path of the solar beam for the next frame, etc.). It's generally a bad idea (I know it is the simple and obvious way of doing things though, and I made this mistake in my 2010 version) to do it the other way around, which would be get player input etc. update and move everything draw everything You can get away with that if you use a double buffer of course. That wastes a lot of memory and as well as drawing to the offscreen buffer (which can be in noncontended RAM, so that's a bonus), you then have to copy it to contended RAM (preferably immediately after the HALT if you have interrupts enabled. In my 2010 version I did use a backbuffer and I had a "dirty list" of cells I had to redraw so it only redraw those, which made the drawing fast. Maintaining the dirty list was a pain though so I soon got rid of that idea in my later stuff. (Of which only one has been released, and it's not great (speedwise and codewise) either, it was while trying to improve it someone decided to draw an 8 frame anim for Willy which started me to rewrite my engine again). It's not a bad game if you like scrabble and columns though (I don't like the occasional attribute flicker you get though) https://spectrumcomputing.co.uk/entry/42215/ZX-Spectrum/SJOE It's like columns but you have to make valid (in Scrabble) 4 letter words (and only 4 letter words count! Hence all words displayed on screen in the UI and the starting names in the high score are all valid 4 letter words (they are random words from the list for the high score names)) 🙂 The entire SOWPODS list of 4 letter words is present and correct (can't remember how many, think it's 5000 odd). You can get a list of them by pressing L from the main menu. Don't turn on CUSS mode if you are easily offended by scoring points for words 🙂

I also only save and restore the stack pointer once when rendering all the guardians, Willy, the keys, the exit and the solar power beams (which also use the stack to pop 2 entries off the erase/draw list at once - each entry is the attribute address to either set back to the background colour or set to the beam colour). More details about how I am doing the solar power beam in the thread at the Spectrum Computing forum. So it's basically do this: di ; disable interrupts while the stack pointer is changed save sp draw all the guardians in a loop draw Willy draw all the keys draw the exit draw the solar power beam if applicable restore sp enable interrupts again Which means that I am unable to PUSH or POP any registers nor call any functions inbetween saving and restoring the stack pointer. So all the guardian draw routines are jumped to and they jump back to draw_next_guardian when they are done and such. I will probably make the erasing of everything work in a similar way as well. (Well it does already, it has a list of stuff to erase - which is only if a guardian moved and if it moved to the right I only erase an 8x16 strip where it moved out of, and vertical guardians erase the 16xN rows they were previously covering. EDIT: So if they moved 3 pixels down they erase the 16x3 strip above them). I don't think there is much benefit of using the stack for that since it is just writing 0s to the screen. I erase everything I need to before drawing anything - otherwise the big evil priest in JSW would not work properly if I erase each guardian and then immediately draw it). Erasing Willy is more complicated it needs to redraw the cells he is standing in front of (and it will also need to redraw any crumbly cells he is standing on).

I'm not using an off screen buffer at all, all my drawing is direct to screen. Most of the draw routines use the stack to read the sprite data (so can read 2 bytes of data in 10T states which is as fast as you can read data on the Z80, much faster than LDI). I'm not using the stack to blit to the screen though, it turns out to be slower doing it that way because you have to keep reloading SP. This is the body of the draw horizontal guardian routine anyway. The stack gets set to the graphics data (32 bytes) and HL points at the screen address of top left of the sprite REPT 4 pop de ; 10T ld (hl), e ; 7T inc l ; 4T ld (hl), d ; 7T pop de ; 10T inc h ; 4T ld (hl), d ; 7T dec l ; 4T ld (hl), e ; 7T inc h ; 4T ENDR ; ; move to next cell down ld a, l ; 4T calculate screen address to start of next 8 lines add #20 ; 7T add 32 to screen pointer ld l, a ; 4T jr c, .addr_ok ; 7T/12T jump if addition resulted in overflow (this means we are at next 64 line segment) ld a, h ; 4T (nc) sub 8 ; 7T (nc) subtract 8*256 ld h, a ; 4T = 37T if jump not taken .addr_ok ; 27T if jump was taken REPT 4, idx pop de ; 10T ld (hl), e ; 7T inc l ; 4T ld (hl), d ; 7T pop de ; 10T inc h ; 4T ld (hl), d ; 7T dec l ; 4T ld (hl), e ; 7T IF idx < 3 inc h ; 4T ENDIF ENDR ; I'm also drawing in a zigzag fashion which complicates the vertical guardian draw, I need 2 versions depending on whether the guardian is at an odd or even Y coordinate.

I'm rewriting my 2010 version and it's optimised, I will release source code once it is in a playable state. It runs at 50fps even with the tune. Willy has 8 frames of animation instead of 4 but they will need adjusting. EDIT: Guardians only update at 25fps but if they had 8 frames of animation they could also update at 50fps, they are being redrawn each frame. I'll be releasing a rolling demo this week (which is the attract mode from the original, just show all 20 levels, no Willy movement or collision code is done yet - which I expect will take less than 2 weeks) Sneak preview So you'll have to do a good job to beat that I think 🙂 + No backbuffer or attribute buffer (draws directly to screen beating the raster)... saves at least 4K of memory + All the level data is currently only less than 3K (does not include graphics data though)... so can have at least 50 levels with an 8K budget for level data. I will also pack the levels into a bitstream (so something that only needs 5 bits only uses 5 bits) which should save around 25-50% on the data size. + With a 12K budget for level data we could be looking at MM and JSW in the same 48K of code perhaps. - the code is large since it is written to run fast rather than care about code size (for stuff done every frame anyway) EDIT: Thread about it on Spectrum Computing forum https://spectrumcomputing.co.uk/forums/viewtopic.php?t=11662 I will write a level editor at some point as well (which will run on the Speccy, may require 128K, dunno), probably whilst waiting for more new graphics/auditioning extra levels