Threads

[Pancho]

Hi everyone, I have made this 2D game which although it is rather simple, it uses very large high quality graphics so it pulls a lot of memory and it is hard to improve performance. What I am planning to do now is to improve performance by using threads. I was thinking about using threads so I could do some tripple buffering, i.e. one thread will be copying from backBuffer1 into the screen while backBuffer2 is being assembled, and vice versa. And also I could experiment having a separate thread for i/o events.

I only have experience with threads with UNIX, does anybody know where can I find more info (sample code NOT for Carbon or in Pascal) on how to use and handle threads ? And also, I think that threads for the mac are available only for OS 8 and higher, am I wrong ? I hope I am wrong because this game has to work on OS 7.

Thank you very much,

Pancho

[OneSadCookie]

A) You will not improve performance using threading, except possibly on dual-processor boxes, or unless you spend a lot of time waiting for a system resource (like in swapBuffers for GL -- CopyBits doesn't count).

B) You will make your life miserable by attempting to thread things.

C) Preemptive multithreading is only available as of Mac OS 8.6. Below that it's cooperative, which kind of destroys your point. I don't know if there's any threading API below 8 or 7.5 or so.

D) Have you profiled your code? Where's the bottleneck?

[henryj]

Didn't we have this discussion last week?

[Baldock]

Maybe it should go in to the wiki / faq then.

On a side note, if the game needs to run in Mac OS 7.x then you have to remember the machines which run 7.1 to 7.6.1. For the most part you are looking at 68k processors with 256k to 4MB of VRAM on 8mhz to 32 mhz buses. Machine ram might be from 1 MB to 128MB for a fully worked Quadra.

Now Myst managed to have very high graphics for the time and I believe it runs under 7.1 on any 68020 with a CD drive, but all it was doing was displaying the pre-rended pictures, and it wasn't doing it fast either.

You might want to re-target your game or re-think how you plan to attach the low-end market space.

[Pancho]

Originally posted by OneSadCookie
A) You will not improve performance using threading, except possibly on dual-processor boxes, or unless you spend a lot of time waiting for a system resource (like in swapBuffers for GL -- CopyBits doesn't count).

B) You will make your life miserable by attempting to thread things.

C) Preemptive multithreading is only available as of Mac OS 8.6. Below that it's cooperative, which kind of destroys your point. I don't know if there's any threading API below 8 or 7.5 or so.

D) Have you profiled your code? Where's the bottleneck?

YEs I profiled the code. The bottlenecks are found 1) in the section in which I render the back buffer with all the sprites and 2) in the section where I copy the back buffer onto the screen. The first bottleneck takes longer because it uses copymask instead of copybits. That's why I thought it would be faster if I used 2 back buffers and render one while the other one is being copied into the screen.

Please tell me why do I need preemptive rather than cooperative threads ?

Thank you

[OneSadCookie]

What you want to do is do two things at once -- copy to the screen, and fill the next back-buffer. With cooperative threads, this is downright impossible; your application, even from your perspective, can only be doing one thing at once. Once you say "blit to screen", you won't be able to say "switch to the other thread" until that call is finished.

With preemptive threads, which thread executes when is out of your control, so it can feel like they're working simultaneously. On a single-processor machine, though, only one thread can actually be working at once, so you don't normally get any actual performance benefit (slight performance penalty for the extra thread-switching is usual).

I've answered the rest of your post in another thread.

[henryj]

I don't use quickdraw so I'm only guessing here but the first place to look is you sprite drawing. Unless there is a REALLY good reason to use copymask, don't. Try and change your sprites so you can use copybits.

Write your own blitter. This, like writing a 3D engine, seesm to be a right of passage for games programmers. And, like writing a 3D engine, tends to be an exercise in futility. Feanor can probably help you with this.

Then have a look at your buffer swap. Is your back buffer in vram? If not why not. vram to vram copies are as fast as it is possible to do. You might even be able to store your sprites in vram. There are regular threads on mac-games-dev about this.

Try and use asynchronous blitting functions. This means that the function returns straight away even if the drawing on the video card hasn't finished. I don't know whether you can do this with quickdraw though.

Plus you can do what OneSadCookie with dirty rect which is what quickdraw used to do to speed up drawing windows to the screen.

In my opinion your best bet would be to port it to opengl.

[Pancho]

Originally posted by henryj
I don't use quickdraw so I'm only guessing here but the first place to look is you sprite drawing. Unless there is a REALLY good reason to use copymask, don't. Try and change your sprites so you can use copybits.

The sprite drawings are very high quality. The screen is 800x600 with thousands of colors. Plus the artist is using a lot of anti-aliasing, which prevents us from having a different color background and thus we can't use CopyBits.


Write your own blitter. This, like writing a 3D engine, seesm to be a right of passage for games programmers. And, like writing a 3D engine, tends to be an exercise in futility. Feanor can probably help you with this.


Do I have to go into assembly code ? Sounds like something you shouldn't try at home. We must deliver by xmas.


Then have a look at your buffer swap. Is your back buffer in vram? If not why not. vram to vram copies are as fast as it is possible to do. You might even be able to store your sprites in vram. There are regular threads on mac-games-dev about this.


This sounds like the best alternative. I will look into it at once.


Try and use asynchronous blitting functions. This means that the function returns straight away even if the drawing on the video card hasn't finished. I don't know whether you can do this with quickdraw though.

Plus you can do what OneSadCookie with dirty rect which is what quickdraw used to do to speed up drawing windows to the screen.

In my opinion your best bet would be to port it to opengl.
[/QUOTE][/B]

I am already using dirty rects. Is there OpenGL for OS 7.6 ?

Thanks a lot for the info.

[OneSadCookie]

The sprite drawings are very high quality. The screen is 800x600 with thousands of colors. Plus the artist is using a lot of anti-aliasing, which prevents us from having a different color background and thus we can't use CopyBits.

I hate to say it, but even if you get this running on 7.5, the kind of hardware that runs 7.5 is not going to be able to cope. That generation of hardware has enough problems with a 640x480x8 full-screen game with a bit of action! Ask Zwilnik what Airburst is running on, because the requirements sound similar. I think you'll find that a mid-speed G3 is required for that sort of quality.

Do I have to go into assembly code ? Sounds like something you shouldn't try at home. We must deliver by xmas..

You will very seldom need to write assembly code (though occasionally the compiler does something really stupid with register allocation which might necessitate that). Being able to read the assembly code to find out what the compiler's done, though, is a very useful skill.

VRAM GWorlds only work on OS 9 (and maybe OS X; they didn't used to).

OpenGL requires OS 8 (or is it 8.1?). It's unlikely to be faster than your own blitter for machines without HWA OpenGL, though, which is a large part of your target audience, it seems.

[henryj]

Go and have a look at Ambrosia software. Check out their games and the machine requirements. This will give you a good idea of what is possible on what hardware.