I was just thinking as a few years ago we were pretty level in terms of power regarding games but Im not sure whether the Acorn as it is now could cope with even say Rollercoaster Tycoon. And what will these new gfx cards have as an effect on what runs???

Sorry I got bored and thought a rambly thread was in order...

________
[Steve]
RiscPC SA & Duron 600@850
ICQ: 51028779

Reasons against:
* Not many computers with FPA's
* All the mod's would have to be converted
* Unless we want another ArcQuake, the engine would have to be re-written mainly in assembler
* No 3D cards yet
* HL needs quite a bit of RAM to run now
* It would just add another conversion to the list of Acorn games, instead of a completely new idea.

However, if anyone wants to try it then I am available

Absolutely

Will it run faster than a speeding glacier?

Probably not.

Actually, assuming the conversion was for Omega, Kinetic and Evolution (if it ever arrives) then it might be feasible (I give an Omega or Evolution with XScale the most realistic opportunity though).

Ok we don't have FPAs. So we rewrite the code to use fixed point math. As for completely rewriting it assembler....well I don't think that'd be productive. Certainly profile the code and reimplement time critical parts, but not the whole thing.

The mods would only have to be converted if the market was strong enough to support them. First thing would be to get the game running.

Finally I'm interested in how you know TBAQuake was better than ArcQuake. Have you got a copy of the source lying around?

The point being that, even with a "lesser" machine, it's a great game and very playable. A StrongARM machine might be okay, and an XScale machine much better (bearing in mind Omega has the lightning chipset too), so I don't think that should stop us. Licensing costs, programmers, ah now that's a differet matter...

For Half life, etc...

How much does such a licence cost??

For Half life, etc...

I would imagine that it would be tens of thousands for a license currently.

I'm pretty certain that TBA Quake outperformed ArcQuake. Their engine was at least partially re-written in assembler and Acorn-optimised, while ArcQuake is basically the C source recompiled. I also have a demo from one of the Acorn User CD's, called fast quake. It draws E1M2 at 640x480, with the light map and sky at an average speed of 14fps. Obviously this is quite a bit less than what real Quake does, but I'm sure it would be better than ArcQuake if it was carried through.

But did you see it? My point is that I can write code in assembler and "optimise" it, and then find the compiler has done a better job than me. Assembler isn't some magic "write in it and everything will go faster" language like lots of people seem to think. Personally I think the RISC OS market is far too fixated with assembler in general - look at the hassles we're having now getting onto new hardware, with old apps that won't run etc etc.

I do write ARM code, but these days I figure the performance drop of C is worth it if I can write code 20 times quicker (and I'm someone who still develops on an A4000 so I dunno what all you StrongARM owners are bleating at ).

IIRC fast quake was also missing a lot of features from the original - in fact didn't it just draw the levels? Adding the models and stuff will add a fair overhead.

I don't think Fast Quake is TBA Quake; it was just a demo. Okay, we never saw TBA Quake, but it was apparently not far from completion and shows what can be achieved.

That's why I'm fairly confident that technical issues are not what would stop a HL port.

The TBA version of quake was supposed to be very much faster because they were hoping to use it for Quake II as well as Quake I; and we all know which game engine Half-Life uses don't we?

"Supposed to".

Sorry, as someone who has seen both computers and software disappear just as he was about to buy it over the last few years I'm less inclined to believe things unless I see them myself these days.

Anyway, apparently Martin Piper no longer has the source although it is supposed to be "out there"

I don't think Fast Quake is TBA Quake; it was just a demo. Okay, we never saw TBA Quake, but it was apparently not far from completion and shows what can be achieved.

Fast Quake was written by Jan ....(I forget the surname) and the C/ARM source code can be downloaded from

http://aglaee.imag.fr/AcornDemos/FtpArea/3D_engines/

It's a BSP viewer with about 15k of C code and 2k of ARM macros. Note that a BSP viewer is a long, long way from a usable game engine.

That's why I'm fairly confident that technical issues are not what would stop a HL port.

Fair enough - lack of developers, time and money are a good enough brick wall anyway.

[Edited by 9 at 16:12, 18/11/2000]

[Edited by 9 at 16:16, 18/11/2000]

so, theres quite a few mods to keep us happy with ArcQuake (although if u've got a pc nearby use that cos the SA's Floating Point stinks), also go to www.fileplanet.com and look under the mod. sections there too.

ARRRGHHHH Why are modems so slow!!!! ahh well, Risc OS message boards provide a bit of entertainment whilst dloading Front Line Force

And here are a couple more Quake mods:
* Fiend Hunter 1 http://fh1.telefragged.com
One of the more advanced mods that goes as far as changing the Quake exe, plus an older version is available for ArcQuake (I suppose it will run). There are however a few bugs and missing features, and development seems to be running low. A little hint if you try the current version though - add '-console' to the command line to get access to the console (ala HL), and put your controls in the autoexec.cfg (or delete config.cfg from the pak file), otherwise it gets stuck on Xoltan's setup.
* Your Path Of Destruction http://www.planetquake.com/doom
Is basicallly Doom in the Quake engine, and looks pretty good too.


[Edited by 17 at 17:04, 20/11/2000]

The only sensible direction to go in, would be to a) Decide which 3D graphics standard to support.
b) Write a software implementation of this.
c) When the 3D cards come out, replace the OpenGL module with a driver for your graphics card.

Particularly with the prospect of hardware graphics cards in the future, unless a 3D standard is adopted for RISC OS, then a lot of time and effort will be wasted by various people.

At this late stage, we should not be having different coders each implementing their own texture mapping algorithms. This is a waste of effort.

Whether or not we ever get decent graphics cards, we need a software 3D standard to progress at all. We have software emulation to implement other standards (e.g. Floating Point).

This strategy (concentrating the best coders on the task of implementing a graphics standard) would also increase the number of less-skilful coders able to produce impressive looking games dramatically. You would be looking at a revolution in PD software.

Everyone is missing the point!
Nowadays virtually all games are built upon graphics standards, which are implemented in hardware cards on most modern PCs.

Not everyone. I've advocated MiniGL as a first step in one of the other threads.

The only sensible direction to go in, would be to
a) Decide which 3D graphics standard to support.

The only sensible option is OpenGL. Converting Direct3D, while possible, would be difficult to reproduce exactly due to it's COM based nature and also you're at the mercy of Microsoft. Microsoft would probably shut you down faster than you could say "the lawyers are coming"

b) Write a software implementation of this.

Or port one. Mesa is too unweldy for what we want though.

c) When the 3D cards come out, replace the OpenGL module with a driver for your graphics card.

Yep BUT both the software and hardware drivers have to contain the sam functionality. This is not always the case with OpenGL as it's a large API (hence the MiniGL drivers).

Whether or not we ever get decent graphics cards, we need a software 3D standard to progress at all. We have software emulation to implement other standards (e.g. Floating Point).

We can always convert the floating point to fixed point underneath the API.

Also so I can get as many posts as Tim - lagging behind y'see

Everyone is missing the point!
Nowadays virtually all games are built upon graphics standards, which are implemented in hardware cards on most modern PCs.

Not everyone. I've advocated MiniGL as a first step in one of the other threads.

I'm going to look up stuff about OpenGL... even a minimal implementation would be a very exciting development!

Whether or not we ever get decent graphics cards, we need a software 3D standard to progress at all. We have software emulation to implement other standards (e.g. Floating Point).

We can always convert the floating point to fixed point underneath the API.

Who would take on such a project? Martin Piper? I think not, having had his fingers burned over Quake...

You cannot have a tree without roots. A port of Half Life would be one of the topmost leaves of a hypothetical tall tree that is currently only a small sapling planted in a stagnant swamp.