G-Wars

I recently spotted this game from NovaCoder at EAB.

https://eab.abime.net/showthread.php?t=119350

The game requires a high end 68k system i.e. PiStorn and uses RTG and AHI. It can be found below.

https://aminet.net/package/game/shoot/G-WARS

I gave it a try on OS4.1 on my X1000 as it should in theory be compatible but the results are not as they should be.

https://www.youtube.com/watch?v=vHRxqHyVO5E

I wonder if anyone else can test on other OS4.1 systems to see if they have the same issue.

@Rob

I think vsync is a option in the monitor driver, check that’s it's enabled, if game only uses vsync, it can run too fast, sense vsync depends on the screen mode, or perhaps did something else, best to contact Nova Coder about the problem maybe he can explain. or fix the bug.

@LiveForIt

The only tooltypes relating relating to vsync in the monitor driver are for setting the minimum and max. Both are set at 60 on my system.

If a game uses vsynch it it should just lock the frame rate in relation to the refresh rate of the monitor. It more about maintaning a consistent frame rate than limiting the speed at which the game itself runs.

If you compare my video to NovaCoder's own video you can see there are issue beyond the speed at which the game runs. The game scrolls or jumps beyond the boundaries of the gamneplay area and object are also drawn beyond that boundary.

Black listing the game so it runs using interpreted 68k emulation makes no difference, well maybe a few more seconds before the game over message is displayed.

MorphOS user have reported it to be running fine on their systems although one did have a problem with the player ship not being drawn correctly.

@Rob

There are many ways time kept in AmigaOS, one is timer.device, timer.device can measure time in cpu clock cycles ticks or milliseconds, ticks are synchronized to refresh rate, so ticks are not same between NTSC and PAL Amiga computers and therefore should not be assumed to be fixed number of clock cycles. Doing so is a bug.

This hack should slow down your clock cycles ticks to old Amiga 500 pal amiga.

https://os4depot.net/?function=showfil ... tility/misc/timerhack.lha

Another way to keep time is cia chip a/cia chip b timer a and b, if hardware banging is used for timing then NallePuh, it should fix timing..

WaitTOF in graphics library we talked about before, should sync to video modes refresh rate..

refresh rate is behind the “@” in screen modes, typical this are auto detected using DDC.. but custom screen modes can be added to the screen mode icons. Refresh rate is typically 60hz on LCD, on CRT it can be as high as 90Hz. Old school Amiga 500 is typical 25Hz/33Mhz, for TV syncing.

https://forum.amiga.org/index.php?topic=63099.0

@Rob

Quote:

MorphOS try’s to have same clock ticks as a Amiga 500, while AmigaOS4 decided to have a higher precision clock based on real time clock, (so it’s not dived down.)

In any case if the game was not broken, timing should work, only Nova Coder can fix the bugs in his game..

And nobody else them him know how it should work in his game.

@LiveForItQuote:

They are not actually what I would call bugs, G-WARS is compiled to run on Amiga 3.x so if it doesn't work correctly on other operating systems then that's not much of a surprise to me. Saying that, I coded G-WARS to be be very platform independent, someone could compile an AROS/OS4/MorphOS version in about 5 mins I guess.

If someone here does fancy building an OS4 version then they should wait for me to update the repository with the latest changes (v3.0).

@Rob

it’s better than what I get with my PiStorm32-CM4 and OS3.2.3. I get blank spaces on the opening screen. NovaCoder said on EAB it’s most likely to P96.

@ NovaCoder

great to see you here

@328gtsQuote:

Hi mate :)

Yes it seems to have trouble with the newer Individual Computers builds of P96. When I get time, I'll change my development tools over to use the newer P96 to get it working.