nesdev.com
http://forums.nesdev.com/

Pre-emptive thread scheduling using MMC3 irqs?
http://forums.nesdev.com/viewtopic.php?f=2&t=16776
Page 2 of 2

Author:  tokumaru [ Mon Dec 04, 2017 9:38 am ]
Post subject:  Re: Pre-emptive thread scheduling using MMC3 irqs?

ccovell wrote:
If I recall, Tepples, or some other person here, made a "Sprite" demo where each sprite was its own thread. So a demo has been made.

I think that was blargg. IIRC, the demo consisted basically in giving each object its own PC, that was restored before its logic ran, and then backed up for next time. No interrupts were used, each object was responsible for transferring control to the next.

Author:  GradualGames [ Mon Dec 04, 2017 10:37 am ]
Post subject:  Re: Pre-emptive thread scheduling using MMC3 irqs?

tokumaru wrote:
ccovell wrote:
If I recall, Tepples, or some other person here, made a "Sprite" demo where each sprite was its own thread. So a demo has been made.

I think that was blargg. IIRC, the demo consisted basically in giving each object its own PC, that was restored before its logic ran, and then backed up for next time. No interrupts were used, each object was responsible for transferring control to the next.

So basically coroutines then?

Author:  adam_smasher [ Mon Dec 04, 2017 11:14 am ]
Post subject:  Re: Pre-emptive thread scheduling using MMC3 irqs?

Ideally coroutines would/should save/restore the stack as well.

I implemented a coroutine system for my Game Boy game but ultimately scrapped it because it didn't win me much, and there were costs in terms of performance and complexity and flexibility (I had to be really conscious of my stack height because each routine had such a small one allocated to it).

My favourite thing to use coroutines for is scripting - in an RPG or something, you can write scripts right in assembly, no need for a separate bytecode or managing a state machine or anything.

On a more powerful platform with more spare RAM it might be worthwhile - you could have larger stacks and more memory per process, and you wouldn't take such a large performance hit. You could have tons of different tasks handling different things - collision detection, scripting, animation, physics, etc.

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/