Amiga.org
Amiga computer related discussion => Amiga Gaming => Topic started by: derringer3 on February 23, 2007, 11:42:40 PM
-
I downloaded from aminet the recent version of openttd. (For os3.x) It seems it is an old (2004) archive, aminet just playing some retro cards. Anyway, one of my favourite game on pc was ttd, and running a patched ttd on amiga is a great fun! :-)
I'm running the warpos verion of the game, its speed almost acceptable, but if i switch a higher resolution than 640*480 the game will just became a slideshow. 10 years ago I ran the game on pc and a 486/66MHz was more than enough for it. What do i wrong?
-
must...resist...remark...bah, can't. Run WinUAE ;-)
-
Make sure OpenTTD is running on 8bit screen. Other than that there is nothing to do about it.
-
Is there a line in cfg for it?
-
Nope. SDL should pick one for you when you enter fullscreen mode. Check with Scout it is really 8bit screen OpenTTD is using though 640x480 is already quite good for old Amigas.
-
SDL = Unbearably slow on classic Amigas. Even on a PPC equipped one...
-
Heh! You should try running the 68K version!!!! It's unfortunately unplayable, even on an '060...
What we need is for someone to rewrite it in 68K assembler - after all, the original TTD and TTDx ran fine on a 486SX at 25MHz! Any volunteers?! Didn't think so!!! :-)
OpenTTD's a great game though, can't wait until the map enhancements are made, and some of the new graphic sets that are works-in-progress for the "NewGFX" engine are looking good (http://wiki.openttd.org/index.php/City_Buildings_%28New_Graphics%29)!
- Ali
-
I see that i must wait until os4 arrives at my miggy.
-
One thing I always hated about SDL, the implementation quality varies so much.
I did some testing (admittedly some time ago now) with a WarpOS version and it causes a context switch orgy on basic things such as frame buffer flips and event handling.
There's no excuse for this, really. It's perfectly possible to code manual switches from PPC -> 68K and do all the basic OS calls 68K native (inclusive of gathering IDCMP event data into a small, shared bufffer for the PPC to act upon after returning) and then returning control to the PPC. I've written code that does this and you can get it down to one full context switch per frame and that's with PPC native event handling callbacks too.
-
In that case...deliver :-)
-
If I still had a working PPC classic and a job that didn't consume all my time these days, I might look into it.
-edit-
That said, the strategy for solving problems like this is as I already said.
Never call multiple 68K native OS functions directly from the PPC in time critical sections. Always, and I mean always, write a 68K "entry" function that can then call your OS functions before returning and have the PPC call this.
The solution I used had a Context structure. This contained the Screen, ScreenBuffer and Window pointers, it also contained a small Event buffer (implemented as an array of Event structures). These Event structures contained a type field and a bunch of unions the meanings of which depended on the type. The Context structure also contains several function pointers that act as callback handlers for events.
A PPC native function "update(struct Context*)" would take a Context instance and then pass it to a 68K function via Warpos/Run68K().
This 68K function would then flip the ScreenBuffers and then process the IDCMP events from the Window's IDCMP port using a standard GetMsg() based loop. Processing these events simply involved decoding them and filling up values in the Context's Event array.
Unless you are really unlucky, you'd never fill this buffer between frames though it is an obvious design flaw that it couldn't really hold more than 64 events per frame. Any more than that would end up waiting to be processed in the next frame. However, in practise I rarely managed to get more than four of five between frames even when blitzing the mouse ;-)
Once this was completed, the 68K function would return back to the PPC.
Before completing, the PPC would then step through the events that were received, calling the Context's appropriate callback functions for each event.
The upshot of all this is that you basically got 1 full PPC->68K->PPC round switch when flipping the screen buffer and retrieving the input.
-
@Karlos
Never call multiple 68K native OS functions directly from the PPC in time critical sections. Always, and I mean always, write a 68K "entry" function that can then call your OS functions before returning and have the PPC call this.
In context of SDL and SDL games it is not always easy. It is easier if you write your own stuff or doing custom port but SDL games are supposed to build out of the box...
And I think most of WarpUp porters do not understand context switching problem at all... many just recompiler 68k program for WUP and are wondering why it is slower than original...
-
@Itix
Understood, but somewhere in the implementation of SDL you should be able to realise this particular type of switch-optimizing solution. The user of the SDL library doesn't necessarily need to be aware of any of this.