Full-screen 32 columns bicolor engine NIRVANA+

I'm glad to announce the release of NIRVANA+ ENGINE, providing support for bicolor graphics (multicolor 8x2) in 32 columns for all standard Spectrum models (48K, 128K, +2, +2A, +2B, +3)!

2rwrml4.png

n624pt.png

When the original NIRVANA ENGINE was released about 2 years ago, it supported 30 columns, at most 22 rows in bicolor. Now NIRVANA+ ENGINE supports all 32 columns, at most 23 rows in bicolor.

Now I know exactly what you are going to ask...

Why not 24 rows?
Technically, limiting bicolor size to 24 rows instead of 23 rows would take me no additional effort. But I preferred to reserve the top row on screen for timing synchronization, so the screen will never flicker. Trust me, it's worth it!

Is it harder to use NIRVANA+ in comparison to NIRVANA?
No! Both engines have exactly the same APIs, and behave exactly the same way. Internal implementation has changed, therefore most addresses are different, but that's all!

How much more memory does it use?
Almost none! Latest version of NIRVANA uses 8677 bytes of memory, generating 22 bicolor rows. If you recompile NIRVANA+ to use 22 rows also, then it will use 8728 bytes of memory, a difference of only 51 bytes!

How much more CPU does it use?
None! If you recompile NIRVANA and NIRVANA+ to use the same number of bicolor rows, both engines will consume exactly the same amount of CPU.

Hold on, do we really get 2 extra bicolor columns for free? There must be some disadvantage!
There isn't. You really get 2 extra bicolor columns for free :)

Does it mean the original NIRVANA ENGINE will be discontinued?
No, it's still supported. Choosing NIRVANA or NIRVANA+ for your game simply depends on what you want to happen when drawing a tile at the screen edge. Would you like only half of this tile to appear on screen, so you can easily implement multicolor images gradually entering or leaving the gameplay area? If so, use NIRVANA. Or would you like the entire tile to appear on screen, so you can have an even larger gameplay area? In this case, use NIRVANA+.

Is it free?
Yes! All my multicolor engines are free to develop all kinds of programs (even commercial games), they only need to be properly credited.

Anything else?
This new engine is based on a 32 columns multicolor routine proposed by Alone Coder and later modified by myself. For further details you can check this thread. Thus many thanks to Alone Coder for the 32 columns idea, this engine would not have been possible without him! He's properly credited in NIRVANA+ documentation :)

But how can I get it?
I'm glad you ask, I almost forgot it! The new NIRVANA+ ENGINE is available here.
Post edited by Einar Saukas on
Author of BIFROST* and NIRVANA, host of zxgraph.
Thanked by 2R-Tape abelenki
«134

Comments

  • Thanks a lot for all your effort in the Spectrum, Einar. I think you would have gotten rich back in the day with these new features, still unexplored for the Spectrum, making games look like never before.
    Looking forward to seeing the new games with this second versión of Nirvana ;)
  • Looks brilliant!
    I am from that generation, when Pluto was still a planet, and the Earth is round.

    Bomb Munchies on WOS thread
    Bomb Munchies Ver1930 17th Nov 2017 (look for the blue download box ) If you get a time-out message and live in the UK then try after 9pm-3am.
    Send me a PM and I can email it to you too. Kent, UK
  • Ivanzx wrote: »
    Thanks a lot for all your effort in the Spectrum, Einar. I think you would have gotten rich back in the day with these new features, still unexplored for the Spectrum, making games look like never before.

    Do you mean my Speccy work won't get me rich anymore? Dammit!
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • This looks beautiful i wish i had any understanding of coding TO use iT...id there any place forma me TO start?
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • Looks nice. I'm at the moment really too involved in other real life stuff, but this is another breakthrough in spectrum graphics! Congrats!
  • This looks beautiful i wish i had any understanding of coding TO use iT...id there any place forma me TO start?

    In this case I highly recommend learning BORIEL's ZX BASIC. It's the easiest way to program sophisticated games for the Speccy.

    However, in your case we would loose a very productive game developer, and gain an unexperienced programmer instead! Are you sure it's worth it? The alternatives are trying to find a good programmer to work with you, or waiting until someone releases a development system like AGD or CGD for NIRVANA. That's something I'm considering to do myself if nobody else does it, although it should still take me a couple years to finish my other projects before I'm available to do something like this.
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • Timmy wrote: »
    Looks nice. I'm at the moment really too involved in other real life stuff, but this is another breakthrough in spectrum graphics! Congrats!

    Thanks!!!
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • It's amazing great work!!!

    Congratulations.
    ---
    retrovirtualmachine.org - Emulator for OS X.
  • Amazing stuff.
    Joefish
    - IONIAN-GAMES.com -
  • edited September 2015
    Just 32 columns? Disappointed :-p

    This looks beautiful i wish i had any understanding of coding TO use iT...id there any place forma me TO start?

    For starters I'd recommend having a play with making some sprites and tiles in ZX Paintbrush (.btile is the filetype to open), I bet you could make some amazing graphics. That might lead to collaborations etc.


    Post edited by R-Tape on
  • Respect, awesome engine!
  • Thank you!!!
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • Isn't it amazing that new things are still being worked out on the thirty-three year old Spectrum? It's brilliant what you've done, Einar, very impressive indeed.

    Would this be possible in Manic Miner or Jetset Willy? I've heard that these two games 'waste' time by doing inefficient loops or whatever, so could they be made to support multi-colour sprites (insofar as the games used sprites) and still run, gameplay-wise, at the same speed?
  • You, my dear fellow, are utterly mad for having ever even attempted such an obviously impossible feat. And a freaking genius for having actually succeeded. Jolly well done!
  • ewgf wrote: »
    Isn't it amazing that new things are still being worked out on the thirty-three year old Spectrum? It's brilliant what you've done, Einar, very impressive indeed.

    Thanks!
    ewgf wrote: »
    Would this be possible in Manic Miner or Jetset Willy? I've heard that these two games 'waste' time by doing inefficient loops or whatever, so could they be made to support multi-colour sprites (insofar as the games used sprites) and still run, gameplay-wise, at the same speed?

    I think so. MM and JSW don't seem to require more processing than some of the games already released using NIRVANA. In fact, this is an awesome idea for a new project, if anyone's interested!
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • AndyC wrote: »
    You, my dear fellow, are utterly mad for having ever even attempted such an obviously impossible feat. And a freaking genius for having actually succeeded. Jolly well done!

    Thanks! :)
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • Einar, what about version for pentagon?
    [Stronghold] [l'Abbaye des Morts] [Stronghold2 WiP (30%) defrosen]
  • Certainly on a 128K, with a sound chip to play the music, the enemy sprites are just straight copies into open space, and you could just use a small buffer centred on the main character to repaint his patch of the screen - I'm pretty sure Manic Miner could be reproduced. The number of sprites that need to be redrawn would have to be shared out between successive frames, and probably redraw the player every frame, even if he hasn't moved, just in case he overlaps an enemy. The ropes in Jet Set Willy may be trickier to do without the full-screen refresh loops, but some dedicated code could crack it. The problem might be using top-border time consistently for different customised tasks on different screens.
    Joefish
    - IONIAN-GAMES.com -
  • Jerri wrote: »
    Einar, what about version for pentagon?

    I was planning to release it in a few weeks. There's a minor NIRVANA update I would like to release first.

    Do you need it earlier?
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • joefish wrote: »
    Certainly on a 128K, with a sound chip to play the music, the enemy sprites are just straight copies into open space, and you could just use a small buffer centred on the main character to repaint his patch of the screen - I'm pretty sure Manic Miner could be reproduced.
    Definitely. There are only a handful of cases that I can think of where the Manic Miner engine alters attributes: these are movement of guardians, collection of keys, completion of the crumbling of a platform, activation of the exit, triggering of the Kong switches and the solar power generator beam, which will be a pain. The greatest number of guardians on any level is 7 (Amoebatrons’ Revenge).

    If guardians left a trail of their own attributes instead of restoring them, and these were painted only when necessary, then I wonder whether this could maybe even work on the 48K, too, albeit without sound. I had imagined that there might be too much to do during the uncontended period to get all of the drawing done in just one frame, and one might need to use the 128K’s secondary screen... or at least, a secondary attribute code block.

    BTW, I’m surprised this has not yet been done as it would allow for very nice full-screen cyclic attribute effects, with the only limit being the amount of pixel data that can be altered given the remaining CPU time. Granted, multiple pages are harder to work with, as one may end up multiplying the amount of work to be done in drawing sprites by the number of pages that need to be updated.
    The number of sprites that need to be redrawn would have to be shared out between successive frames, and probably redraw the player every frame, even if he hasn't moved, just in case he overlaps an enemy. The ropes in Jet Set Willy may be trickier to do without the full-screen refresh loops, but some dedicated code could crack it. The problem might be using top-border time consistently for different customised tasks on different screens.
    Hmm, obviously you have a slightly different line of thought to me regarding this! It’ll be interesting to see, should you or anyone else attempt to give this a go.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • Jerri wrote: »
    Einar, what about version for pentagon?

    I was planning to release it in a few weeks. There's a minor NIRVANA update I would like to release first.

    Do you need it earlier?

    i think i can wait.
    i write some monochrome sprite riutines for nirvana.

    [Stronghold] [l'Abbaye des Morts] [Stronghold2 WiP (30%) defrosen]
  • joefish wrote: »
    Certainly on a 128K, with a sound chip to play the music, the enemy sprites are just straight copies into open space, and you could just use a small buffer centred on the main character to repaint his patch of the screen - I'm pretty sure Manic Miner could be reproduced. The number of sprites that need to be redrawn would have to be shared out between successive frames, and probably redraw the player every frame, even if he hasn't moved, just in case he overlaps an enemy. The ropes in Jet Set Willy may be trickier to do without the full-screen refresh loops, but some dedicated code could crack it. The problem might be using top-border time consistently for different customised tasks on different screens.

    FWIW my CPC+ conversion of JSW II handles the ropes without redrawing the screen every frame and the code to do so isn't actually that difficult to do (getting them to feel right at half the horizontal resolution was actually the most painful bit till I finally realised I could just cheat by handling the ropes in high res and fudging the drawing). I'd assume you can get away without worrying about attributes whilst drawing them too as I don't think there are any places where enemy sprites move in the way of ropes.

    Custom code for special rooms shouldn't be too much of a problem, for the most part it tends to be relatively simplistic in practice (The Solar Power Generator probably being the most tricky) and I assume you could claw back some CPU time by keeping the bicolour section to just the main playing area.
  • joefish wrote: »
    Certainly on a 128K, with a sound chip to play the music, the enemy sprites are just straight copies into open space, and you could just use a small buffer centred on the main character to repaint his patch of the screen - I'm pretty sure Manic Miner could be reproduced. The number of sprites that need to be redrawn would have to be shared out between successive frames, and probably redraw the player every frame, even if he hasn't moved, just in case he overlaps an enemy. The ropes in Jet Set Willy may be trickier to do without the full-screen refresh loops, but some dedicated code could crack it. The problem might be using top-border time consistently for different customised tasks on different screens.

    Agreed.

    The rope doesn't need multicolor, just draw it directly on screen. If all empty spaces have yellow INK for instance, and erasing characters during movement also leave same INK color, then drawing ropes directly on screen bitmaps will simply appear as yellow, with no need to do anything in multicolor.

    Enemies just move up/down or left/right in fixed paths like in "El Stompo", also they never collide with each other or scenery AFAIK. Using standard NIRVANA sprites to draw them will work perfectly. There are never more than 8 moving entities per screen (including player) and every entity image is at most 16x16 pixels. It means we can simply reserve a tile sprite for each entity and let NIRVANA draw them automatically every frame. Whenever an entity moves, just erase it on screen, POKE a new sprite position, and NIRVANA will automatically draw it again next frame.

    Player movement is tricky, since it requires pixel precision. The player can get so close to an enemy that both may occupy the same 8x8 character. When it happens, we don't want parts of enemy or player to disappear, when drawing one of them over the other. But there's an easy solution. Use last sprite number to draw player, but draw player pixels using "OR" with background (instead of copying them over existing background). Therefore if player and enemy get too close, you will see a temporary color clash on enemy, but pixels won't disappear. This won't be worse than color clash from original game in same situations anyway.

    Coincidentally I already implemented last week a drawing routine using "OR". It's slower than just copying image to screen, but using it for player only won't be a problem. I will publish it later.

    Using 128K would give plenty of space to store multicolor versions of enemies and scenery graphics, perhaps recreating each original room with more visual variety. All graphic details could be decompressed before starting each room, so the gameplay itself could always run in 48K only.

    I'm not a big fan of Manic Miner so I won't take this project myself. But if any experienced enough coder is seriously interested to develop this project, then I would gladly assist by implementing the multicolor related routines!
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • I've a feeling you need 8 enemies plus Willy (they were certainly the limits I worked with), although that may only be necessary for some of the rooms in JSW II or if you count arrows in JSW, I can't quite remember.
  • Jerri wrote: »
    Einar, what about version for pentagon?

    The Pentagon version of NIRVANA+ is ready! Download it here.
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • good thank you
    [Stronghold] [l'Abbaye des Morts] [Stronghold2 WiP (30%) defrosen]
  • Einar i have a question
    ; synchronize with raster beam
    ld b, 92 ; extra delay
    djnz $ ; extra delay
    djnz $ ; extra delay
    nop ; extra delay
    nop ; extra delay
    jp race_raster ;56552 #dce8
    ;
    org 56693 ;#dd75 ;141 byte free
    ; race the raster beam to update attributes on screen at the right time
    race_raster:

    why this piece of code looks so strange?
    Why here once org?
    [Stronghold] [l'Abbaye des Morts] [Stronghold2 WiP (30%) defrosen]
  • Jerri wrote: »
    why this piece of code looks so strange?
    Why here once org?

    It was my intent to make Pentagon version as close as possible to the standard version. This way, a coder developing for both Pentagon and standard Spectrum could use exactly the same source code for all cases. Also everything I wrote in the documentation (including all mentioned addresses), and z88dk and ZX BASIC interfaces work for both Pentagon and regular Spectrum without any changes.

    This empty gap of 141 bytes free was necessary to ensure that the "entry-point for additional interrupt routines" provided by NIRVANA+ will be at exactly same address in Pentagon and standard Spectrum. So if you want to POKE a call to your own AY player for instance, you won't need to use a different address in each case.

    You will also find another smaller gap of 8 bytes free at address 65004 for a similar reason.
    Author of BIFROST* and NIRVANA, host of zxgraph.
  • Einar Saukas
    Why did not you use kernal for routine access ?

    somewhere in the end of the code block
    somethink like

    jp NIRVANA_start
    jp NIRVANA_stop
    jp NIRVANA_printC
    jp NIRVANA_printC
    ...
    and so on

    Einar, you disappoint me.

    [Stronghold] [l'Abbaye des Morts] [Stronghold2 WiP (30%) defrosen]
  • Jerri wrote: »
    Einar Saukas
    Why did not you use kernal for routine access ?

    somewhere in the end of the code block
    somethink like

    jp NIRVANA_start
    jp NIRVANA_stop
    jp NIRVANA_printC
    jp NIRVANA_printC

    Because adding these instructions would waste 12 bytes! I didn't want to waste even a single byte in original NIRVANA+ implementation.

    Although there are some empty gaps in Pentagon port (since it's shorter), they are located in addresses occupied in original NIRVANA+ version. Therefore your code shouldn't use these addresses anyway, otherwise your program won't work on both Pentagon and standard Spectrum anymore. I didn't want to sacrifice compatibility, just to move around 2 small gaps that programs shouldn't use anyway. Makes sense?
    Jerri wrote: »
    Einar, you disappoint me.

    Ouch! :)
    Author of BIFROST* and NIRVANA, host of zxgraph.
Sign In or Register to comment.