DAAD to zx spectrum

[firelord]

What is the easiest way to transfer a DAAD adventure script to ZX? I used adventuron and exported the DAAD script.
From my research so far I found that DAADReady is the best/easiest option.

The problem is that I use linux and DAADReady is 64bit windows program (=my WINE runs only 32bit) and usually its a problem to reboot to windows just for one test.

Is there anything easier?

[firelord]

Also, with DAADReady I can only create 128k .TAP file.
The zx48tape.bat says "xmessage" is not supported.

[8BitAG]

What is the easiest way to transfer a DAAD adventure script to ZX? I used adventuron and exported the DAAD script.
From my research so far I found that DAADReady is the best/easiest option.

DAAD Ready! is just an easy way of running a batch script that compiles the source code and combines the whole thing with an interpreter sending the files into an emulator ready for quick testing. One of its advantages is that bundles emulators and batch scripts for all the platforms that DAAD supports... meaning that you can quickly test your game on multiple platforms.

The actual core of the new DAAD, DRC (the DAAD reborn compiler) will run on Windows, Linux and MacOS. Plenty of people use DRC with Linux so it'd be worth popping a question to the community on Discord about automating the procedure for testing on that operating system. Using DAAD DRC standalone isn't as easy as using DAAD Ready... that's one of the reasons DAAD Ready was created.

Also, with DAADReady I can only create 128k .TAP file.
The zx48tape.bat says "xmessage" is not supported.

Xmessage isn't supported in the 48K tape version, because Xmessage is one of Uto's new feature extensions that loads extra messages from disk or 128K memory. If you want a 48K-only game then you may need to manually edit the code to change the Xmessages to standard DAAD messages (or system messages). There is an upper limit on both the number of messages, and the memory available, should you choose to use the standard DAAD messages.

[Jbizzel]

Also, with DAADReady I can only create 128k .TAP file.
The zx48tape.bat says "xmessage" is not supported.

Tried this on windows last night and got a similar error. Plus3 worked fine and created a dsk file.

[8BitAG]

Tried this on windows last night and got a similar error. Plus3 worked fine and created a dsk file.

Yes, xmessages won't work on the 48K so the source code would need to be manually tweaked to compile for 48K... Perfectly possible (and quite a quick process) as long as the game isn't too big.

The +3 version loads the extra messages off disk, using an extension called Maluva.

The best thing to use instead will eventually be the new 128K DAAD interpreter, which loads the messages from 128K memory... as it's a lot faster than loading them off disk (and also targets the other non-disk 128K machines). I've got some versions of games that I want to release using this... but I'm currently waiting for a minor (but quite visible) bug in the interpreter to be fixed.

[firelord]

Thanks for the answers.
I accepted the 128k (for now) and I added graphics.
The route I go is Adventuron->Export DAAD+Graphics->DAADReady
I put the TEST.DSF in the same folder as ZX128TAPE.BAT and the exported images to the folder images. The convertion produces a .TAP file that doesn't load (no error message). Any idea?

[8BitAG]

Thanks for the answers.
I accepted the 128k (for now) and I added graphics.
The route I go is Adventuron->Export DAAD+Graphics->DAADReady
I put the TEST.DSF in the same folder as ZX128TAPE.BAT and the exported images to the folder images. The convertion produces a .TAP file that doesn't load (no error message). Any idea?

Doesn't load when the batch file fires up the emulator as part of the Daad Ready process? Or the output file doesn't load?

You mentioned images... I'm not sure how well the 128K interpreter supports images... The GitHub page is here... https://github.com/cronomantic/ZXDAAD128
I'm waiting for a new version of that before I play about with it more.

Have you tried building a +3 version from your source?

[firelord]

Doesn't load when the batch file fires up the emulator as part of the Daad Ready process? Or the output file doesn't load?

I don't know the emulator of DAADReady but the process runs without error . A TAP file is created in the DAADReady/RELEASE/ZX128TAPE/. So far everything is just like the vesrion without graphics. The TAP did not load though. Because I do the convertion in windows 10 and the development in linux I might be missing something.

You mentioned images... I'm not sure how well the 128K interpreter supports images... The GitHub page is here... https://github.com/cronomantic/ZXDAAD128
I'm waiting for a new version of that before I play about with it more.

Have you tried building a +3 version from your source?

I haven't tried that -I wanted a ZX spectrun 48k or 128k version -for the original ZX Spectrums. I will try it next time I reboot in windows.

[firelord]

...

Have you tried building a +3 version from your source?

At this point I have tried +3 , 128 and 48 . If I enable images it crashes (stucks at before the start of the game).
I decided to remove images and

My latest problem is that while in web version I get items easy, it the converted versions when I try to get an item I get a message that says that item is too heavy. I added weight = "0" but I haven't a 64bit windows near me to try it (with DAAD ready)...


Also, I have another issue :
I do (in the web classroom)

Code: Select all

print "    A\n                      B" 

but it ignores spaces . It prints :

Code: Select all

A
B

Is there a way to add spaces in the start of the line?

[Jbizzel]

Tried this on windows last night and got a similar error. Plus3 worked fine and created a dsk file.

Yes, xmessages won't work on the 48K so the source code would need to be manually tweaked to compile for 48K... Perfectly possible (and quite a quick process) as long as the game isn't too big.

The +3 version loads the extra messages off disk, using an extension called Maluva.

The best thing to use instead will eventually be the new 128K DAAD interpreter, which loads the messages from 128K memory... as it's a lot faster than loading them off disk (and also targets the other non-disk 128K machines). I've got some versions of games that I want to release using this... but I'm currently waiting for a minor (but quite visible) bug in the interpreter to be fixed.

My game us super tiny at the moment, but when I compile a +3 disk version it loads every individual statement from disk. So the game is very slow.

I need to figure out how to change the code so I can compile a tap.

At the moment I'm at CGC territory

Nice tool, and very well documented to get you going with the basics and beyond

[firelord]

My game us super tiny at the moment, but when I compile a +3 disk version it loads every individual statement from disk. So the game is very slow.

I need to figure out how to change the code so I can compile a tap.

At the moment I'm at CGC territory

Nice tool, and very well documented to get you going with the basics and beyond

I manage to compile to 48k by doing this in the .DSF file :
First i removed the first lines :

Code: Select all

#ifndef "nomaluva"
#extern "MALUVA"
#endif

Then I removed the "X" from all the commands :

Code: Select all

XMESSAGE , 
XSAVE , 
XLOAD

[firelord]

Also, I have another issue :
I do (in the web classroom)

Code: Select all

print "    A\n                      B" 

but it ignores spaces . It prints :

Code: Select all

A
B

Is there a way to add spaces in the start of the line?

I got an answer from discord for that. The problem appeared only in the browser. In the compiled it printed the spaces.
This lead to another issue I had the characters "__|__" but it did not showed them in ZX. I changed it to "--|--" and they are visible now.

Also, the "The item weights too much for you" problem still exists after I made all objects weight="0". ( The problem exists ONLY in the ZX versions -not in the browser/classroom version)

[8BitAG]

My game us super tiny at the moment, but when I compile a +3 disk version it loads every individual statement from disk. So the game is very slow.

I need to figure out how to change the code so I can compile a tap.

Well, there are two options. Either leave the source code as it is and use the new 128K DAAD interpreter. That does currently have a bug involving article/pronoun replacements for objects, which may or may not affect you. The devs are aware of that and I'm personally waiting for a fix before I release anything using the 128K interpreter.

The other option, which can be used if your game is small, is to go in and change the XMESSAGE condacts in the source code to MESSAGE ones. There are only a limited number of messages available... the compiler will automatically combine any duplicate messages into a single entry in the database, but if you run out of MESSAGEs then you can use the SYSMESS condact instead. You might have to adjust the line spacing accordingly. MESSAGE adds an automatic newline when printed. SYSMESS does not. (You can use MES for MESSAGE if you don't want a newline).

It's not that difficult/time-consuming to swap out the XMESSAGE condacts for MESSAGE etc as you can use your text editors "find" functionality to locate them in your source.

[8BitAG]

Also, the "The item weights too much for you" problem still exists after I made all objects weight="0". ( The problem exists ONLY in the ZX versions -not in the browser/classroom version)

I would check what the object weights are in your DAAD source code... Look in the /OBJ section. After each object (e.g. /0) the first number is the starting location of the object (it may well have a named location in your source code) and the next value is the object weight. You could check and adjust the values here.

The limits on how many objects a player can carry (stored in flag 37) or the total weight of objects a player can carry (stored in flag 52) can be set using the ABILITY condact. Dropping ABILITY 255 255 (i.e. setting both to maximum) into an appropriate place in your game code would resolve any issues, but I don't know how familiar you have become with editing the source file.

At the end of the day you are now creating a DAAD game, rather than an Adventuron one, so learning how DAAD works will help considerably when it comes to fixing the bugs and glitches that *will* appear when you export a game to run using that system.

[firelord]

I would check what the object weights are in your DAAD source code... Look in the /OBJ section. After each object (e.g. /0) the first number is the starting location of the object (it may well have a named location in your source code) and the next value is the object weight. You could check and adjust the values here.

The limits on how many objects a player can carry (stored in flag 37) or the total weight of objects a player can carry (stored in flag 52) can be set using the ABILITY condact. Dropping ABILITY 255 255 (i.e. setting both to maximum) into an appropriate place in your game code would resolve any issues, but I don't know how familiar you have become with editing the source file.

Thanks.

At the end of the day you are now creating a DAAD game, rather than an Adventuron one, so learning how DAAD works will help considerably when it comes to fixing the bugs and glitches that *will* appear when you export a game to run using that system.

I started looking for something to create from PC a script for PAW (something like Basin for BASIC). Everything needed windows.
I went to Adventuron because a)It had an adventuron2Paw convertor and b) I could test realtime my game in my browser (linux/tablet).
During the development I learned that adventuron2Paw is old and does not work.
Adventuron2Daad worked better so I decided to try DAAD. I managed to convert my initial game from DAAD to ZX. After a while I realised that this had nothing to do with PAWS so i could not continue development/dolast touches on spectrum.
At somepoint I realised that I must use directly DAAD or at least try to modify it. I found EAAD editor but it didn't help a lot because I did not know the syntax. I looked for a manual and I kept finding DAAD_Manual_2018.pdf which is 13pages only and doesn't help. The last 2 days I found DAAD_Manual_1991.pdf which is the full manual.

My main problem so far seems to be that everything needs windows 64bit so it is very difficult to do any normal development & testing...

[8BitAG]

I started looking for something to create from PC a script for PAW (something like Basin for BASIC). Everything needed windows.

That isn't strictly true. You can build inPAWs in Linux. https://github.com/Mastodon-/inpaws

My main problem so far seems to be that everything needs windows 64bit so it is very difficult to do any normal development & testing...

Again, this isn't strictly true. DAAD Ready! is Windows only but DAAD Ready! is just a tool to help authors streamline the process of compiling and testing the game quickly on multiple formats and then building a release version. A lot of its Windows-only nature is because it bundles in all the emulators for the various platforms.

DAAD Ready! is only a recent production. We've been using DAAD for the past few years *without* having access to it and the only real difference is that you have to do certain steps manually and it just takes a little longer each time. The core DRC program will happily run in Linux and you can use the DOS version, through DOS box as a quick testing environment to iron out any major bugs without having to make a Spectrum build of your game each time.

It's just a case of finding a system that works for you. Because you've chosen Adventuron to make things easier to develop at the start, it does now mean that you're finding the end process trickier. Believe me, although it may not seem like it to a newcomer, things are a lot easier now than they were originally... In the past I ended up manually porting games between Adventuron and PAWs/DAAD, and converting PAWs games to DAAD, because we didn't have access to all these great tools.

Even though I release DAAD games, I still personally almost exclusively develop using inPAWS these days, because I like producing something that I know I can load into PAWs and that is guaranteed to work on a 48K Spectrum. Once I'm happy with my PAWS "prototype" I'll port the code to DAAD so that I can release it on other systems, such as the C64, Amstrad CPC, Amiga, Atari ST, DOS PC etc.

You're always going to be able to make a more optimised game by developing directly for a platform. Exporting from an Adventuron game will always produce more bloated and complicated code than something you would make yourself in PAWS & DAAD, simply because it is having to generate code in a way that copes will all sorts of uncertainties.

One thing that might help you in the future is that there is a browser-based interpreter for DAAD on the way. That, in conjunction with DRC on Linux, might enable you to string together a nicely optimised workflow.

[Jbizzel]

Thanks for your help:)

Compiling [Frontend]
DAAD Reborn Compiler Frontend 0.25 (C) Uto 2018-2022
Reading TEST.DSF
Checking Syntax...
2:16:TEST.DSF: Extern file "MLV_ESX.BIN" not found.
"Compile error, please check"
Press any key to continue . . .

Hi I changed xmessage to message in the DSF file. I still get the same error for ZX48TAPE.bat

[8BitAG]

Thanks for your help:)

Compiling [Frontend]
DAAD Reborn Compiler Frontend 0.25 (C) Uto 2018-2022
Reading TEST.DSF
Checking Syntax...
2:16:TEST.DSF: Extern file "MLV_ESX.BIN" not found.
"Compile error, please check"
Press any key to continue . . .

Hi I changed xmessage to message in the DSF file. I still get the same error for ZX48TAPE.bat

Maluva (MLV-ESX.BIN) doesn't work with the 48K interpreter. You need to comment out the code that calls that (at the beginning, which I think you said you did) and also replace any of the Xcondacts in your source. I think Firelord mentioned that he took out the XSAVE and XLOAD as well... I'm not completely sure what Adventuron export is using these days.

[Jbizzel]

I manage to compile to 48k by doing this in the .DSF file :
First i removed the first lines :

Code: Select all

#ifndef "nomaluva"
#extern "MALUVA"
#endif

Then I removed the "X" from all the commands :

Code: Select all

XMESSAGE , 
XSAVE , 
XLOAD

Thanks - I had to remove xpicture too, and now it has compiled

[firelord]

First of all
My goals are :
1. CGC games and
2. (if I'm happy) I might use it for a creating simple adventure story with my students(which adventuron seems very good/capable).

...
One thing that might help you in the future is that there is a browser-based interpreter for DAAD on the way. That, in conjunction with DRC on Linux, might enable you to string together a nicely optimised workflow.

That would be a good thing. Browser support allows development in Adroid too .

My next project would be in InPaws. I started with InPaws/ngPaws but switched to Adventuror (for the reasons I mentioned above).Also,I agree with the PAW loading ability for the final touches.

I swiched to adventuron in the beggining because I had touble finding good tutorials manuals (I did not want youtube videos). During my search I discovered adventuron.

Thanks - I had to remove xpicture too, and now it has compiled

You managed to compile something with pictures in zx48k ?

[Jbizzel]

@firelord

compiling it for the spectrum has resulted in my 'conspicuous="false"' items being displayed when you enter a room. Have you had that issue?

This doesn't happen in the HTML version that gets created.

I'm working on adding images - Ive not tried to do it yet. I've started making them, but want to get the core "game" in place first.

My goal is a simple CGC entry that helps me learn how to do the different things I need to do, then potentially code a bigger game.

[Mpk]

compiling it for the spectrum has resulted in my 'conspicuous="false"' items being displayed when you enter a room.

I was just about to ask about exactly the same thing. Glad to know it's not just me.

[8BitAG]

compiling it for the spectrum has resulted in my 'conspicuous="false"' items being displayed when you enter a room. Have you had that issue?

This is always going to happen because the concept of "conspicuous items" isn't something that exists in PAW or DAAD. The objects are either in the location or they're not. They can't be in the room and invisible. So, you're going to have to tweak the code for those if you don't want them listed under the "You can also see:" LISTAT prompt.

It depends how you've used those items... If it's just a case of scenery objects, that you don't want the player to pick up, then instead of checking if the object is present (in the code) you'd just tweak it so it checks if the player is AT a specific location instead.

I'm working on adding images - Ive not tried to do it yet. I've started making them, but want to get the core "game" in place first.

You can't have images in the 48K tape version... You'd need the 128K interpreter or the +3/ESXDOS versions for that.

At least, not bitmap images. You could code traditional PAW/Quill-style line and fill drawings.

[firelord]

I haven't use conspicuous items but I think you can simulate them by "creating" the item when needed. just don't put the at= when you define the object

[Mpk]

For me, I'm using it to allow the user examine scenery in the room description.

if_examine checks location first, but you can replace
:if_examine("thing")
with
:match "x thing"
, which seems to work. And is in fact better, as you don't even need to define an object.