English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 31 December 2017, 03:05   #1
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
Converting a "system-takeover" game to OS friendly

Hi,

I have been working on a new option for an up-coming game to provide an OS friendly configuration (as opposed to system-takeover) for those with a bit of extra CPU and external devices that can cause problems for "system-takeover" games and demos (I'm looking at you TCP/IP and USB stacks!). Note: I will still be supporting the "system-takeover" versions for lower spec machines or those that don't care about running a TCP stack behind a game.

I took my info mainly from "howtocode7" as well as the gloom source code and some EAB posts on various things like keyboard input.

I have made a bunch of changes and so-far with the exception of a small performance hit on slower CPUs it seems to be working. But I thought I would outline what I did in case anyone can make any suggestions or see's something I have missed.

So this is what I did:
  1. Replaced the standard "demo startup code" with new code I wrote. This actually does less than what most demo startup code does. So far all I do is:
    • Handle the workbench messages etc (this is unchanged)
    • Save the current view
    • Save the copper pointers
    • Load a null view
    • Own the blitter
    • Disable sprite DMA (my game doesn't use sprites as it stands)
    • Set the task priority to 20 (anything higher than this seems to prevent input.device from sending me events)
  2. Replace my VBLANK vector hijacking with AddIntServer calls with appropriate system compatible changes to the handler routine.
  3. Replace my direct hardware keyboard routines (including PORTS vector hijacking) with an input.device handler that looks for keyboard events and swallows them preventing keyboard events reaching workbench (my game has no window).
  4. Run P6112 player in "system friendly" mode.
  5. Only change DMA for copper/raster/audio and leave it as I found it.
  6. Restore view/copper/dma/disown blitter on exit with appropriate system clean up

So far from the testing I have done, it seems to be working well both in emulation and on real hardware, however I don't have any hardware that creates unwanted interrupts (not sure if my PCMCIA card generates PORTS interrupts).

Any suggestions would be greatly appreciated
alpine9000 is offline  
Old 31 December 2017, 11:11   #2
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
To be 100% sure you do not have to worry at all about unwanted interrupts, TCP/USB stacks, special keyboard drivers, etc, you can :
- Open an Intuition screen and a backdrop/borderless window on it.
- Use IDCMP messages rather than input.device.
- Allocate audio with audio.device (then you can touch audio HW).
- Own blitter only when you use it, not for the whole program's duration. Or better, not use the blitter at all if you know the machine has a fast CPU.
- Do not touch task priority (no real positive impact on accelerated machines and it could block an important task).
- Use system calls like WaitTOF() rather than empty polling loops, for timing.

I also humbly suggest you isolate everything that is accessing hardware or OS into some kind of system framework, so that you can reuse it at will for all future projects.
meynaf is offline  
Old 31 December 2017, 11:23   #3
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
Quote:
Originally Posted by meynaf View Post
To be 100% sure you do not have to worry at all about unwanted interrupts, TCP/USB stacks, special keyboard drivers, etc, you can :
- Open an Intuition screen and a backdrop/borderless window on it.
- Use IDCMP messages rather than input.device.
- Allocate audio with audio.device (then you can touch audio HW).
- Own blitter only when you use it, not for the whole program's duration. Or better, not use the blitter at all if you know the machine has a fast CPU.
- Do not touch task priority (no real positive impact on accelerated machines and it could block an important task).
- Use system calls like WaitTOF() rather than empty polling loops, for timing.

I also humbly suggest you isolate everything that is accessing hardware or OS into some kind of system framework, so that you can reuse it at will for all future projects.
What’s the reason for using a screen/window versus input.device?

I’ll look into allocating the audio, seems the polite thing to do.

Thanks for the pointers.
alpine9000 is offline  
Old 31 December 2017, 11:44   #4
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Quote:
Originally Posted by alpine9000 View Post
What’s the reason for using a screen/window versus input.device?
Well i am not sure that else, all special keyboard drivers would work (for people not using true Amiga keyboards, like usb or serial).
It is also a lot easier to use the mouse.

And anyway it allows your program to multitask happily.
You can then use Amiga-M to return to OS (for whatever task you want to do) without quitting the game, grab the screen with any Amiga screen grabber, use tools such as Snoopdos/Enforcer, etc.
I haven't done it myself, but you could add support for gfx cards as well.
meynaf is offline  
Old 31 December 2017, 11:49   #5
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
Quote:
Originally Posted by meynaf View Post
Well i am not sure that else, all special keyboard drivers would work (for people not using true Amiga keyboards, like usb or serial).
It is also a lot easier to use the mouse.

And anyway it allows your program to multitask happily.
You can then use Amiga-M to return to OS (for whatever task you want to do) without quitting the game, grab the screen with any Amiga screen grabber, use tools such as Snoopdos/Enforcer, etc.
I haven't done it myself, but you could add support for gfx cards as well.
Interesting points, thanks again. I think step 1 is “OS friendly/compatible”, maybe next time around I will try for fully multitasking compatible

It’s a little bit complicated by the fact that the same code base does the trackloaded A500 version.
alpine9000 is offline  
Old 31 December 2017, 11:56   #6
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 3,272
why not writing a whdload slave for your OS friendly game?
jotd is offline  
Old 31 December 2017, 12:04   #7
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
Quote:
Originally Posted by jotd View Post
why not writing a whdload slave for your OS friendly game?
I’ll admit I don’t know much about whdload (other than how to run it), but from what I can see whdload suffers from this same limitations as my “system takeover” games. i.e needing to shut down tcp stacks etc? Correct me if I’m wrong?
alpine9000 is offline  
Old 31 December 2017, 12:11   #8
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Right, whdload indeed takes over the system.
meynaf is offline  
Old 31 December 2017, 12:41   #9
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
Quote:
Originally Posted by meynaf View Post
Right, whdload indeed takes over the system.
How does whdload do disk io? Or does it just load everything into ram?
alpine9000 is offline  
Old 31 December 2017, 13:10   #10
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Quote:
Originally Posted by alpine9000 View Post
How does whdload do disk io? Or does it just load everything into ram?
It loads everything into ram if you use the PRELOAD option (usually the case).
Else it switches to/from OS, like when saving a game. Makes black screen and stopped sound while performing disk accesses.
meynaf is offline  
Old 31 December 2017, 13:13   #11
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
Quote:
Originally Posted by meynaf View Post
It loads everything into ram if you use the PRELOAD option (usually the case).
Else it switches to/from OS, like when saving a game. Makes black screen and stopped sound while performing disk accesses.
Right that’s how my system takeover version works. One big advantage of leaving the OS running is the ability to do disk io nicely.
alpine9000 is offline  
Old 01 January 2018, 00:02   #12
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
So it seems that the P6112 player allocates the audio.device when in system friendly mode.

During my testing however it seems some apps don't correctly respect the allocation protocol (either they don't allocate audio, or don't correctly respond to a channel being "stolen").
alpine9000 is offline  
Old 01 January 2018, 02:04   #13
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 3,272
whdload main advantage is that it does everything properly AND supports MMU (on some machines there's remapping of the zero page, which crashes the games if you don't cancel it because VBR is there )

Black screen is annoying only if there's a lot of data to load. For hiscore saving, if the original file is full of zeroes but saving scores doesn't change the file size, you won't even have black/flash screen. Scores will be saved when exiting the program.

of course, all TCP stacks are killed (but whdload provides ability to execute startup & end scripts to handle external hardware if needed, well, the user must adapt to his config)
jotd is offline  
Old 01 January 2018, 02:06   #14
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 729
Quote:
Originally Posted by jotd View Post
whdload main advantage is that it does everything properly AND supports MMU (on some machines there's remapping of the zero page, which crashes the games if you don't cancel it because VBR is there )

Black screen is annoying only if there's a lot of data to load. For hiscore saving, if the original file is full of zeroes but saving scores doesn't change the file size, you won't even have black/flash screen. Scores will be saved when exiting the program.
Yeah, my games have supported non zero VBR since someone picked up that I missed it with Blocky Skies!

I always test on MMU so I can use Enforcer.
alpine9000 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
"Voices8" 8 Channel Soundtracker "DemoSongI" song - "This is the Amiga with 8 Voices" DemosongIHunter request.Music 44 27 October 2019 20:04
Loonies' "Hotstyle Takeover" breaks on 3.5.0 Foebane support.WinUAE 39 24 September 2017 18:01
How "Brick Games" and "Game' n' Watches" works Leandro Jardim Retrogaming General Discussion 2 03 August 2013 18:48
"Exception "Line 1111 Emulator" ($2c) Error at $1004" when exiting game demolition support.WinUAE 15 30 November 2012 17:43
Suggestion: "Archive" sub-section for "Looking for a game name" andreas project.EAB 1 29 May 2008 02:00

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 17:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08572 seconds with 15 queries