Return to Castle Wolfenstein and Enemy Territory

@all

Moving this since no one is discussing the actual topic anyway.

@Helgis

64 bit support is not possible without implementing new API's, not if you want to retain compatibility with 32 bit programs. Pointers in e.g. structures or tag lists are all 32 bits. Nothing can be done to retroactively change that.

There are two possible scenarios to fix this:

1) Let each application see their own 32 bit address space but with private areas for local memory. The private areas can be mapped on a per-task basis, making use of a larger than 32 bit address space. Application size is still imited.

2) Implement a new set of API's for 64 bit applications.

@Rogue

A bit even more offtopic,but the X1000 has pci-e.. Is that V1.0/1.1 or 2.0?
As there is quite some difference in data transfer between v1 and v2...

@Rogue

Ok, i see the difference. Doing 64-bit would mean a completely stand-alone AmigaOS that is only 64-bit,
but then the compatibility with 32-bit remains..

Perhaps you are trying to say that 64-bit would have
to be considered once AmigaOS4 is fully completed,
and then ready to take the next step, that would probably
be 64-bit or something completely different from what AmigaOS4 is...

I guess with what you are saying, it would be (for now, that is) to push the 32-bit support to the absolute maximum and making the very best out of it. I'm sure there are different methods to do that. Finding the best ones might be more tricky..

I have faith that everything will come out right in the end. Multi-core support will be extremely useful in 32-bit OSes,
alongside Java-support, OpenGL and all the remaining parts that "complete" an OS..

@thread

This gives me a headache. It's in the cons file.....
At the fork it won't do anything more.....

package action::command::unix;

sub do_command {
my($class, $com, $path) = @_;
my($pid) = fork();
die("$0: unable to fork child process ($!)\n") if !defined $pid;
if (!$pid) {
# This is the child. We eval the command to suppress -w
# warnings about not reaching the statements afterwards.
eval 'exec($com)';
$com =~ s/\s.*//;
die qq($0: failed to execute "$com" ($!). )
. qq(Is this an executable on path "$ENV{PATH}"?\n);
}
for (;;) {
do {} until wait() == $pid;
my ($b0, $b1) = ($? & 0xFF, $? >> 8);
# Don't actually see 0177 on stopped process; is this necessary?
next if $b0 == 0177; # process stopped; we can wait.
if ($b0) {
my($core, $sig) = ($b0 & 0200, $b0 & 0177);
my($coremsg) = $core ? "; core dumped" : "";
$com =~ s/\s.*//;
my $err = "$0: *** \[$path\] $com terminated by signal " .
"$sig$coremsg\n";
warn $err;
return undef;
}
if ($b1) {
warn qq($0: *** [$path] Error $b1\n); # trying to be like make.
return undef;
}
last;
}
return 1;
}

@all

Anyone tried to compile this game yet?

@Antique

I was about to ask that now, really.
Wonder about the same, too.

Any news on this port yet for AmigaOS?

@Rogue

OK, Timberwolf and OpenOffice, off course, Java maybe later. But what about having Shogo, Freespace running on OS 4.1.2 (I believe they are not) and being sold?

What happened to SiN (was demoed) and Gorky 17 (was announced)?

In both cases just Linux/MacOS ports are done.

Rather old, but nice games, would satisfy users and generate some revenues to Hyperion.

@djrikki

I gave up. Haven't heard of anyone else trying,or made the port.

Port has been made meanwhile, unfortunately MOS only. See here.

@kas1e

Have you tried to compile this game?

@Rogue

I completely agree regarding what you wrote about games compared to the applications. When you ported games the Amiga situation was different from today, there where more applications released from others. If I have to choose to be able to browse the internet or to play RTCW the choise is really easy .

What I wrote about before though regarding including some old games for nostalgic reasons and fun are a different thing though I think since the games are available for free. There will be a need for a GUI and some transparent way to run them. I also had the idea of using that GUI for downloadable games that could be installed from within the GUI or download from an application store like are popular these days. That store could later be expanded to sell applications and games for AOS 4 but also have old games/applications downloadable for free if agreed by the owner.

Anyway, not a high priority thing right now but something that I think would be good some time in the future. Lots of non-computer-geeks that I know sit there with their Windows box, surf, reads e-mail, face book and then play Hearts, Spider etc etc. Why not include Deluxe Pacman and some breakout game with AOS 4?

But again, a project for the future, consentrate on the much more important features that are much needed in AOS now. I believe though that Amiga needs to get back to the roots a bit more at some point.

Oh, I'd also like to say that I'm sorry for sounding negative from time to time. I like what you've done with AOS a lot and I do enjoy using it. Typing this from AOS 4 right now. It has come a long way when it comes to usability since the first beta, both regarding AOS itself and the new applications like OWB, NetSurf, SabreMSN, WookieChat, now AmIRC, players for sound and video etc, etc, etc. Things could be better, sure, but it is cerntainly not bad.