I updated the archives on my website. The game now uses triple buffering, which should get rid of the fullscreen flickering without vsync. You may also notice a slight increase in the number of executables included in the package
This is just like television, only you can see much further.
OR, depending on program structure you could handle the buffer swapping yourself , suing the code I added for blender.
That was intended for double buffering in a window, but should work for double buffering in screen too. Then you *can* wait for the safe render message.
You'd need to set up your own screen and buffers and set the MGLCC_PrivateBuffers options and explicitly set MGLCC_FrontBuffer and MGLC_BackBuffer,
See
blender/intern/ghost/intern/Window0s4.cpp in the blender source archive for more info.
No, they are about £50 plus international postage of about £35. If I knew that Gallium was years away, I might jump, but if it is 6 months away then I would end up wasting money.
Of course I have no idea how long until or indeed if Gallium will arrive...
@Severin I'm all for having more slaves (of course I have none, they get umm.. paid, yes!). If this app has no OS4 equivalent, and it doesn't run on OS4 already, then sure thing, I can port it. The source looks neat and clean too.
I would love to be able to donate something to get this ported but as I live on benefits (Can't work due to bad health) and those are a third of the poverty line in the U.K. I just can't afford it.
Amiga user since 1985 AOS4, A-EON, IBrowse & Alinea Betatester
BTW, which is the fastest locking method? In the MiniGL sources I noticed a third one in addition the smart and manual: MGL_LOCK_AUTOMATIC. I'm currently using smart locking, is automatic faster?
Smartlock is the best option, which is why it's the default. It tries to minimise the number of lock/unlock cycles while minimising audio stuttering.
You do not want to use automatic locking. It locks and unlocks Warp3D for each and every render operation, and will slow everything down to a crawl.
edit: BTW, I wasn't implying that you should pay me for the port, I was just joking about having slaves.
I know, I was just saying I would if I could. I'd contribute to loads of things if I could afford to. That's the main reason I beta test so much, a small way of giving something back.
Amiga user since 1985 AOS4, A-EON, IBrowse & Alinea Betatester
@Severin I already have a working version from the program. Unfortunately the original method of getting the CPU usage doesn't work on OS4, so I'm going to snitch some code from cpuwatcher.
This is just like television, only you can see much further.
10-15 fps it kind of slow, i have 10-15-20 fps on peg2, and it slower in few times in compare with video from Goos (i.e. on peg2 its playable, but indeed not fast, while on video from Goos it is imho fast enough, not perfect, but fast enough). Probably what we see in video, it is something between 20-40 fps. And while it slower than we want to be, with such adapter its still faster than pure radeon9250 in 33mhz slot. Sure, one can wait 10 years more for gallium (no one know what speed will be, and how much bugs it will or will not have), but if one want the fastest possible today on x1000 in terms of warp3d, then: radeon9250 + such "66mhz" adapter only way to go. Probably if redeon will be 128bit, and not 64bit as for Goos test, then it will be even faster.
edit: yep, Goos confirm it: Quote:
ok with cg_drawfps enabled i see 12-30fps outdoors and 25-46 fps in buildings.
@Severin I already have a working version from the program. Unfortunately the original method of getting the CPU usage doesn't work on OS4, so I'm going to snitch some code from cpuwatcher.
Wow! that's great news, can't wait to get my grubby little mits on it
Amiga user since 1985 AOS4, A-EON, IBrowse & Alinea Betatester