+- Forum (https://www.boriel.com/forum)
+-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11)
+--- Thread: ZXodus][Engine (/showthread.php?tid=568)
ZXodus][Engine - cheveron - 09-02-2013
![[Image: 971988_518944744820483_1531283958_n.png]](https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-prn2/971988_518944744820483_1531283958_n.png)
The ZXodus][Engine is a game engine for 2D and 3D cRPGs (computer Role Playing Games) for the ZX Spectrum +2B. (It will run imperfectly on other 128s) I'm pleased to announce that the ZXodus][Engine will use ZX Basic for the game logic. All of the tricky stuff will be handled by the engine. It has the following features:
9x9 multi-color (8x1 attrıbute) viewport
16 column text window (6x8 font)
256 multi-color (16x16 pixel) 2D tiles
256 multi-color (16x16 pixel) 3D dungeon tiles
128x128 tile world map
36x36 tile mini-map viewer
16 town maps of 32x32 tiles each
16 NPCs per town
11 character classes
two spell systems
melee and ranged combat
Ultıma 4 style dialog system
AY music player
BEEPer sound effects
Happy to answer any questions.
Re: ZXodus][Engine - britlion - 09-02-2013
Exciting stuff.
Can't help but love the logo for starters
Time for a bard's tale remake, anyone?
Re: ZXodus][Engine - cheveron - 09-03-2013
Glad you like the logo. If you wanted to do a Bard's Tale type game you'd need to do an outdoor 3D tile set. However, the indoor one provided would probably be a reasonable starting point.
Re: ZXodus][Engine - boriel - 09-03-2013
This is awesome. I only own a Speccy 48K, +2 (grey) and +2A.
What's the difference with +2B? Why the incompatibility?
Re: ZXodus][Engine - cheveron - 09-04-2013
boriel Wrote:This is awesome. I only own a Speccy 48K, +2 (grey) and +2A.
What's the difference with +2B? Why the incompatibility?
In all probability your +2A is actually a +2B. The real +2A is pretty rare. The +2A has the same motherboard as the +3 but partially depopulated. The +2B has the cut-down motherboard. The +2B fixes the corrupt sound on the +3/+2A. So for people with a +3/+2A they will need to do the sound fix or the sound will be distorted. For people with the toast rack or grey +2 (ULA 128s) they will need to replace the HAL with a GAL from Velesoft that changes the contention to match the +3/+2A/+2B (ASIC 128s). The ULA 128s contend every I/O access and different RAM pages. This doesn't always leave enough t-states per frame to keep the engine going with a large number of sprites, and the ZXodus][Engine pushes the machine to its limits.
Re: ZXodus][Engine - LCD - 09-04-2013
cheveron Wrote:16 NPCs per townCan you please explain how this will work?
11 character classes
two spell systems
melee and ranged combat
Re: ZXodus][Engine - boriel - 09-05-2013
LCD Wrote:Believe it or not, I was planning something like this with ZX Basic (not an engine, but a game). This is why I created ZXBasic in first place!cheveron Wrote:16 NPCs per townCan you please explain how this will work?
11 character classes
two spell systems
melee and ranged combat
Re: ZXodus][Engine - cheveron - 09-05-2013
16 NPCs per town - each town has a table of NPC start positions. Each NPC has a dialog tree. You can script other behaviour such as giving and taking objects. Shops are handled separately.
11 character classes - mage, fighter, thief, cleric and all possible multi-class combos
two spell systems - magic and prayer. point based. points derived from skill stats.
melee and ranged combat - top down combat with ranged and magic attacks able to hit distant targets.
Re: ZXodus][Engine - cheveron - 09-05-2013
boriel Wrote:Believe it or not, I was planning something like this with ZX Basic (not an engine, but a game). This is why I created ZXBasic in first place!If you let me know the requirements of your planned game I'll make sure ZXodus supports them. The engine is the second hardest thing after writing a decent plot so it would be good to get more than one game out of it.
Re: ZXodus][Engine - LCD - 09-06-2013
cheveron Wrote:16 NPCs per town - each town has a table of NPC start positions. Each NPC has a dialog tree. You can script other behaviour such as giving and taking objects. Shops are handled separately.Sounds good. Can it be also used with disabled Multicolor? We are currently working here on Journey`s End II and the biggest problem is the available memory, even after replacing PRINT with my custom printing routine. We only have 10 kb left... But if 128K is supported, our next RPG will use ZXodus Engine.
11 character classes - mage, fighter, thief, cleric and all possible multi-class combos
two spell systems - magic and prayer. point based. points derived from skill stats.
melee and ranged combat - top down combat with ranged and magic attacks able to hit distant targets.
@boriel: Really you are into RPG games too? I hope, you can finish your game.
Re: ZXodus][Engine - cheveron - 09-08-2013
LCD Wrote:Sounds good. Can it be also used with disabled Multicolor?The whole engine is built around the multi-color display. If you don't want multicolor then you're probably better off using a different engine.
Quote:We are currently working here on Journey`s End II and the biggest problem is the available memory, even after replacing PRINT with my custom printing routine. We only have 10 kb left...What kind of text compression are you using?
Quote:But if 128K is supported, our next RPG will use ZXodus Engine.All the game data is stored in banked RAM and the ZXodus][Engine fetches it on demand, so that leaves most of bank 2 available for the game logic.
Re: ZXodus][Engine - LCD - 09-09-2013
cheveron Wrote:My intention was to save memory as tiles in Multicolor mode take almost twice bytes in comparsion with the normal. Also running the games on other Spectrum modells than +2B (which I do not own) is something I want. There are Pentagon, ZS Scorpion, Chrome and other clones.LCD Wrote:Sounds good. Can it be also used with disabled Multicolor?The whole engine is built around the multi-color display. If you don't want multicolor then you're probably better off using a different engine.
cheveron Wrote:There is only little amount of text, so no text compression is used after all, but if, then I will write dictionary type of text compression with on-fly unpacking, so "Prepare for attack" will be divided inty byte sequences, some representing multiple letters: "P re pa re/space/f or/space/a t ta ck": 12 bytes, while original has 18. Print was used for characters, fonts, etc, but its runtime is too big.Quote:We are currently working here on Journey`s End II and the biggest problem is the available memory, even after replacing PRINT with my custom printing routine. We only have 10 kb left...What kind of text compression are you using?
cheveron Wrote:This sounds good. When will it be released? Is there documentation of all features online?Quote:But if 128K is supported, our next RPG will use ZXodus Engine.All the game data is stored in banked RAM and the ZXodus][Engine fetches it on demand, so that leaves most of bank 2 available for the game logic.
Re: ZXodus][Engine - cheveron - 09-09-2013
LCD Wrote:My intention was to save memory as tiles in Multicolor mode take almost twice bytes in comparsion with the normal.It's 64 bytes per tile. That's only 28 bytes more per tile. And tiles are stored in banked RAM. Plus if you're only using 2D or only using 3D you could leave one tile set out completely for an extra 16K.
Quote:Also running the games on other Spectrum modells than +2B (which I do not own) is something I want. There are Pentagon, ZS Scorpion, Chrome and other clones.
The game will run on any 128. It may glitch a little on non-ASIC 128 models. I'm planning a Pentagon release of the game I'm working on so I imagine at some point there will be a Pentagon compatible version of the ZXodus][Engine. It will be a separate build though. Why waste RAM on model detection?
Quote:There is only little amount of text, so no text compression is used after all, but if, then I will write dictionary type of text compression with on-fly unpacking, so "Prepare for attack" will be divided inty byte sequences, some representing multiple letters: "P re pa re/space/f or/space/a t ta ck": 12 bytes, while original has 18. Print was used for characters, fonts, etc, but its runtime is too big.
I'd suggest using digraph compression (which is what the ZXodus][Engine uses). There's no depacking as such, just a bit trigger for printing letter pairs, and the compression is often better than dictionary word compression. http://foro.speccy.org/viewtopic.php?f=6&t=2997&p=33001&hilit=digraph#p33001
Quote:This sounds good. When will it be released? Is there documentation of all features online?Well there's the sticky part. First: it's not going to be ready for some time. There's a hell of a lot of work to do on it, I'm the only one working on it, and my priority for this year is to finish SE Basic 4.1. Second: I'm probably not going to finalize it until after the game that I want to release using it is written. That's going take even longer. Third: I'm not giving it a public release. I've put all my previous efforts out there for anyone to use and in return I've been publicly vilified by people who have benefitted from my work. Therefore I am keeping the ZXodus][Engine closed source, and I will decide who gets to use it. That said I'm happy to license it to yourself and Boriel. Licensees will get full techincal support. The licenses won't cost anything, but I will expect a cut of the profits of any commercial releases.
Re: ZXodus][Engine - LCD - 09-12-2013
cheveron Wrote:Okay, that sounds not so bad after allLCD Wrote:My intention was to save memory as tiles in Multicolor mode take almost twice bytes in comparsion with the normal.It's 64 bytes per tile. That's only 28 bytes more per tile. And tiles are stored in banked RAM. Plus if you're only using 2D or only using 3D you could leave one tile set out completely for an extra 16K.
cheveron Wrote:So it cannot be modified for another machine just by patching the code of the engine a little with few POKEs?Quote:Also running the games on other Spectrum modells than +2B (which I do not own) is something I want. There are Pentagon, ZS Scorpion, Chrome and other clones.
The game will run on any 128. It may glitch a little on non-ASIC 128 models. I'm planning a Pentagon release of the game I'm working on so I imagine at some point there will be a Pentagon compatible version of the ZXodus][Engine. It will be a separate build though. Why waste RAM on model detection?
cheveron Wrote:From the text it sounds exactly the same, but optimised for spanish texts. My routine I used in the 80's had also no depacking, just triggering.Quote:There is only little amount of text, so no text compression is used after all, but if, then I will write dictionary type of text compression with on-fly unpacking, so "Prepare for attack" will be divided inty byte sequences, some representing multiple letters: "P re pa re/space/f or/space/a t ta ck": 12 bytes, while original has 18. Print was used for characters, fonts, etc, but its runtime is too big.
I'd suggest using digraph compression (which is what the ZXodus][Engine uses). There's no depacking as such, just a bit trigger for printing letter pairs, and the compression is often better than dictionary word compression. http://foro.speccy.org/viewtopic.php?f=6&t=2997&p=33001&hilit=digraph#p33001
cheveron Wrote:Excellent. How much % of the profit do you want for licensing it for comercial releases? Or is the licensing based on something other?Quote:This sounds good. When will it be released? Is there documentation of all features online?Well there's the sticky part. First: it's not going to be ready for some time. There's a hell of a lot of work to do on it, I'm the only one working on it, and my priority for this year is to finish SE Basic 4.1. Second: I'm probably not going to finalize it until after the game that I want to release using it is written. That's going take even longer. Third: I'm not giving it a public release. I've put all my previous efforts out there for anyone to use and in return I've been publicly vilified by people who have benefitted from my work. Therefore I am keeping the ZXodus][Engine closed source, and I will decide who gets to use it. That said I'm happy to license it to yourself and Boriel. Licensees will get full techincal support. The licenses won't cost anything, but I will expect a cut of the profits of any commercial releases.
Re: ZXodus][Engine - cheveron - 09-13-2013
LCD Wrote:It all comes down to the contention model. The Pentagon has no contention at all and so it needs completely different display code. The ULA 128s contend all the I/O access and so they will occasionally run out of t-states per-frame, and they also have different banks of 128 RAM contended. Most of the time it won't be that noticeable and doing a ULA 128 specific build wouldn't address the I/O issue. I would hope that standard Pentagon timings would be sufficient for most Russian machines.cheveron Wrote:The game will run on any 128. It may glitch a little on non-ASIC 128 models. I'm planning a Pentagon release of the game I'm working on so I imagine at some point there will be a Pentagon compatible version of the ZXodus][Engine. It will be a separate build though. Why waste RAM on model detection?So it cannot be modified for another machine just by patching the code of the engine a little with few POKEs?
Quote:From the text it sounds exactly the same, but optimised for spanish texts. My routine I used in the 80's had also no depacking, just triggering.Yes it does sound the same. I think I misunderstood you the first time around.
Quote:cheveron Wrote:The licenses won't cost anything, but I will expect a cut of the profits of any commercial releases.Excellent. How much % of the profit do you want for licensing it for comercial releases? Or is the licensing based on something other?
I appreciate that it's hard to break even on new releases for the Speccy, let alone make a profit. The percentage has to take into account a lot of factors: the actual amount of profit per sale (could be zero for instance), how much I contributed besides the engine, expected number of sales, and so on. But I will always agree the deal in advance before development begins so that the developer isn't left wondering how much of a return they will see on their work.