In fact, there was somebody trying to port GutenPrint, but still no useable result. I tried as a tester, and it was... well... not good ;)

Nice work!

Seems I should dig into IDLTool to make xad/xfd/xpk-OS4 includes...

Edit: missed that they're already there on OS4Depot

@salass00

I would think so

Anyway, it´s of interest for me I´m often nagged to do a new backup tool with compression/divide of the backup to a number of backup media etc. XAD would be a nice-to-have for such things (besides XPK).

@LiveForIt

Sometimes it depends on the source code organization. If the files containing the whole code are organized in static modules, (global) variables like SysBase might not be visible within a certain file if they are not declared "extern".

If you don´t want to mix machine dependend code with "portable" code, it´s best practice not to mess up the "portable" code with machine dependend globals.

Locals must be initialized local, if you don´t declare them "extern" (and define the variable containing the needed value elsewhere). If the "local" variable is declared "extern", this does indeed mean that it´s a global. That´s what SysBase is in most cases. A global. For OS4, it´s a variable defined by the startup code.

Here (in this function TimerFunc() ) it is a question of context, if "extern" makes sense or if the local declaration of SysBase is meant for "clean" code.

If the function is running within the scope of the startup module, "extern" makes perfect sense (and it would lead most certainly to a crash, if you discard the "extern" qualifier). But in this case the initialization is unnecessary. SysBase is initialized already (by the startup module).

If it´s running outside this scope, the correct value of SysBase should be provided by parameter and could be used directly then.

Back in 68k times it was quite usual to initialize a local SysBase by "SysBase = *((struct ExecBase **) 4); " (although most today´s compiler´s startup code provides for SysBase), but with the advent of zeropage protection, this is bad practice.

For me, this function´s code looks a bit messy. On the one hand, global SysBase is used (MOS and OS4 port), on the other hand, "bootstrap" initialization of SysBase is used (obviously, meant for 68k systems). The scope is quite unclear here...

Edit: If the code compiles without the "extern" AND without the initialization, there must be a global SysBase already somewhere within the source file. But then it should throw at least a warning about redefinition... weird.

@LiveForIt

Quote:

Hmm... if it´s the SysBase defined by the startup code, the "extern" makes perfect sense here. SysBase is defined "elsewhere", and it should not be a local (automatic) variable of TimerFunc(). That´s what "extern" means here.

But what about this code running outside the main code´s scope?

I think that´s the reason for the "SysBase = *((struct ExecBase **) 4);" thingie. SysBase is declared inside the function (as a local, and here the "extern" indeed doesn´t make any sense. "static" would be the better choice, maybe) and must therefore be initialized with something that makes sense...

But if this is a function running within the main code´s scope only, it´s total nonsense to declare SysBase over and over. Bad coding practice

@kas1e

Yes, this is suitable and the (IMHO) best solution.

We needed to replace it, because SysBase = *((struct ExecBase **) 4); does a zeropage access (from "user space"), which shouldn´t have been done at all...

Removing is impossible, because sometimes you need an anchor to access OS functions. On other systems this is done e.g. using an interrupt.

I don´t know why it is used in this part of code, but I don´t think that it´s done just for fun

@kas1e

A one-time-appearance of it within the whole code doesn´t necessarily mean that it is called only that one time.

Please, just replace it with anything suitable and go on making Odyssey work

@Chris

I used the code of this

http://aminet.net/dev/src/CompositePOC.lha

to understand how Compositing works.

Its a bit complex, too (and sometimes a bit weird ;) ), but its not as complex as Hans´ demo (which is great, btw.!).

It´s nearer to the application you´d have for CompositeTags(), because its typical 2D programming (replace blits by CompositeTags() using vertex mode and several source bitmaps, including some bitmaps bigger than the "blit" target).

I learned a lot about vertex mode reading this code.

@Hans

Would it be a good idea to use the CompositeTags() call to replace standard Blt...() calls (like BltBitMapRastPort())? E.g. for blitting a background buffer to a window? Would it be faster?

Edit: oh, missed that somebody already mentioned it

Hm, I think it was a mixup of MUI-OWB and RA-OWB AND Voyager standard ARexx commands, mainly. There was indeed a problem with OWB 1.9 with lines using double and single quotes together. Never found out what the reason was.

Maybe there was a problem with the single quotes? Sometimes the ' is mixed up with `, even in source code.

Btw., "OPENURL" would have been more consistent to the SAVEURL command, as they dont differ in what they actually do (opening/saving URL). Other way around, if SAVEURL is just named "SAVE", its consistent, too.

I think you can close the BZ just stating the (more or less) obvious:

"Sometimes its an OpenURL configuration error. Dont use "OPENURL" command, as its NOT an OWB/Odyssey ARexx command. The right command is "OPEN" (see the readme for details). Quotes (single and double ones) work as expected."

Would be a bit more friendly than your statement



Edit: First part edited... some typos... middle part edited

I did a quick check and for me OPEN NAME works as expected, and the NEWPAGE parameter does, too.

I know the OpenURL issue from the OWB version before (1.9), but I think it was the different naming of the ARexx commands?

Settlers 2 licence was claimed to be aquired by Titan Computer (they made Papyrus Office for MOS, too). But I dont think they ever really had

@jap:

Go, go, go! I tested some rough port some months ago and it was fun (although the code wasnt really finished back then). As far as I read on FB, you use the midi sound/music? Any chance to make the mod music available?

@Rigo:

I dont like to bother YOU with some mistake made by other people. If ssolie now knows of the mistake, good.

Yes, the same idea I had when this happened with 1.57, too...

I changed the date part of Rangers version string using a binary file editor. The date part of its version string is the problem here. I used FileX, but any other binary editor should do, too.

ssolie should take more care with this, making the AmiUpdate entry FIRST, and re-check the date string.

Thx for the hint... perfect timing PM sent...

Edit: and he left the moment I pressed "Submit" I will patiently wait for an answer then

Hi!

I wonder how to get in contact with him. I tried via the email address he gave, but all my mails are rejected (recipient not accepting mails, tried from several accounts/mail services).

Its about the rMouse driver, of which I made a derivate to support Cherry Xero mouses (got it fully working, finally, but the lag problem remains). I want to give it to the public (os4depot) as soon as the lag problem is solved and might need his permission to do so...

@AmiDARK:

Have a look at os4depot, too. Theres is some datatype example code in the upload queue right now. It might help you understanding the messaging system of AmigaOS in conjunction with sound.datatype.

@Elwood:

I believe youre interested in some explanation of AHI double buffered replay, too? Thats a part I used myself, too (with InsanePlaya, a CD player). It was a quite complex task, as I used a separate player process and the messaging grew into a message mess, but I think I understood the concepts...

@elwood:

Well, Im no AHI expert, that is I dont know if my knowledge of AHI is deep enough to make up some SDK-quality documentation and examples. I will try my best, and if it suits for SDK documentation/examples, youre free to use it for this purpose.

I tried to understand the AHI examples and managed to use AHI for AmijeweledRTG at last. And I made some tests using AHIs library interface. They were successful. So I think I understand AHI good enough to explain the simple things about it

@Hans:

It seems that it didnt become standard because nothing has happened after the alpha release?

Do you know if theres any chance to get the source code of this work to improve it in a way that it will become standard in the near future? Datatype is a (still) nice system for the handling of all computer art related data, and it should support modern hardware for sound, too...

@AmiDARK:

I could explain AHI to you by email, if you like. May take some time, but in the end youre able to use AHI and do sound coding at a higher level.

I used AHI sound for AmijeweledRTG, and after some experimentation, it was quite easy to use for simple playback of sounds (multichannel, btw.).

The advantage of using AHI is that youre able to play, interrupt and stop sounds (even modify, if you dare to use the library interface of AHI) at any time.

And yes, you could wait for a sound finished. But with action in the meantime

@Hans:

So it is time for an updated sound.datatype, isnt it?

I tested it, too. I have Compositing enabled. Spiral blanker runs as ermh... good as before (there is some synch issue, but I think this is blanker engine related)

The boing ball blanker is a bit slower than before (well, it never was really fast), but all other are running ok here.

@Chris:

Hmm... perhaps any stdlib calls in there, needing dos.library (hence needing a process)?