OpenRedAlert for AOS4x

@K-L

ehh that is what I need :) just try this and RedAlert on my A1 is working :) time for big pizza + cola...and ? play this great game ;)

@K-L

Thanks, I'm going to try later

@ikir

Here it doesn't work.. i can see the intro, but after i get a black screen.. the intro is good but the sound is a little bit distorted.. that' s strange because swapping to workbench screen i can see the cpu usage very low...

I just tried it. After copying the two *.mix files to the openredalert directory, I started the game. Everything worked fine until I started a new game and selected "allied." The audio for the first video clip was messed up (just static). The next video clip worked. Once in the game, it crashed (DSI) when I tried to move all the units over to the right and down through the side.

Hans

I tested this game on my Linux box too. And it showed a message on screen that all missions are not fully implemented and the cheat mode is enabled. Use F9 to skip missions. I found that the first mission of both allied and soviet are impossible to play so I skipped them.

@K-L

As far as I know, MAIN.MIX and REDALERT.MIX files should be copied into
"Data/Mix/" within OpenRA drawer.

OpenRedAlert still does not work here. I copied the two mix files from CD to the OpenRedAlert directory but after I start the game (by either typing "openredalert" in shell or doubleclicking the tool icon in WB) I get the intro (tank is blown to pieces), then a DSI appears. If I choose to ignore it screen which looks like the game's main screen appears. I can't see any text on in, nor select anything with the mouse. I can't even exit the game as nothing works.

What am I doing wrong?

Edit: Ok, I downloaded the exe again, and now I can get to same situation as Hans - game crashes in the beginning of the first mission when I move the troops downwards.

@Alpyre

No, this won't work if you copy these files the place you mention (that's what I thought first and then, seeing it did not work, I copied thes 2 files id the OpenredAlert drawer and it worked).

@All
Anyway, the game is not so stable and many encounter crashes at different moments in the game.

@K-L

i've used a stck cookie of 30MB (MB!) on the source code and on my A1 was quite stable.. maybe on other systems has some problems.. by the way the game is in an alpha state so don't expect too much from it

@afxgroup

You mean that OpenRedAlert in general is in alpha? Or the Amiga OS port? With other Linux source code I've found that Linux developers can get away with sloppy coding more easily than Amiga developers can (i.e., bugs that would crash on Amiga OS just happen to not crash Linux due to other factors such as the system clearing memory to 0).

Hans

@Hans

yes, i mean Openredaletr in general. the recompilation was simply, but if a game needs 30MB of stack.. there is something wrong..

@afxgroup

OpenRA is indeed "alpha" in general, but its issues have *nothing* to do with high stack. Setting 30MB is really useless. Maybe it could sometimes "hide" some overrun bugs, but that's it. And it wouldn't prevent from overwriting other local vars anyway. And by the way, most of OpenRA issues are about unitialized vars and heap management. Stack usage in-game is less than 16kB most of the time, and actually rather close to 2kB in game.

I still wonder why some people consider setting insane values of stack can help in any way. It looks like voodoo magic to me.

@djstormx + all

Checking stack usage with Ranger shows rather usually that apps uses quite small amount of stack but using a large stack helps in stability with some apps. My guess is using big stack buggy apps can happily overwrite their own stack (unused parts of it) instead of overwriting memory that belongs to other apps or the OS. So I welcome virtual memory addressing and full memory protection in future for our OS. It looks like all Linux (and maybe Winblows ones also) apps are very buggy. (Maybe coders don't find those bugs because the memory protection in other OSes hides all bugs transparently and silently.)

@TSK

Some programs do require huge stacks not because they are buggy but because they allocate large buffers on the stack instead of allocating from the free store and/or use heavy recursion.

nrg2iso f.e. needs a lot of stack because it allocates a 1 MB buffer in it's main function and a 34 KB buffer in the checkIso function, both from the stack.

On an OS that has automatic stack enlargement (AmigaOS doesn't unfortunately) this is not a problem of course.

@salass00

So why these apps uses stack instead of other memory then ?

@TSK

Because programmers are lazy and/or simply don't know any better?

It's easier to just write:
char buffer[1024*1024];

than to write:
char *buffer;
buffer = malloc(1024*1024);

In the latter case you also need to check for failure (not all programmers do this though) as well as remember to free the memory afterward. Of course if the OS has resource tracking then the memory is freed automatically but this happens only on program exit.

The stack buffer OTOH is freed by the compiler as soon as it goes out of scope (end of statement block where it's defined).

@djstormx

because i've tried it with standard stack and it crash.
when i have upper the stack all GR gone away.. so it is not so useless..

@afxgroup

I used a ridiculous stack and played for well over an hour. I hope this engine develops further, everything worked fine, it probably will given EA released the CDs for free. I suspect the crash was not Amiga related but memory and I have 1gb in my XE.

ace

@acefnq

crashes of ported programs usually are related to program itself as pointed out from many users, but while other os "protect" the bugs, our OS don't..
Actually I think that AmigaOS is the best OS to find bugs into the code..

How is this port going guys? Is there any progress?