How to optimize hblank, vblank, loop ?

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Sat Mar 15, 2014 3:25 pm

r57shell wrote:I don't know such particular cases.
In my anim sprite library, I had to cut my logic in too part (update() and updateVBlank()) to follow the what-could-be-called-MVC model.
It was very boring because it works almost 90% of the time...but fails when "something" (the time taken on loop before the update()) get wrong.
It's now working but I spent too much time to rewrite the logic.
You could argue I had to think to it before (and you'll be right!) but it happens ;)

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sat Mar 15, 2014 5:01 pm

KanedaFr wrote:;)
It makes me remember of a talk I had with Stef asking if he planned to port SGDK to asm. His answer was something like "I don't see the reason to do it, FOR NOW" (@stef, correct me if my memory bugs!)
Yeah it was almost that ;) ASM will be faster but SGDK is made for simplicity, readability and not performance it is why almost code is done in C. Still SGDK should be fast enough for common tasks and some parts are wrote in ASM when we need it. If a user really need the best performance he can write very optimized ASM methods to replace the SGDK ones.

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Sat Mar 15, 2014 5:27 pm

So far, most of my problems with performance using C has been algorithmic. Spending time to rework a loop or refactor some heavy code has always bumped up my framerate in a nontrivial way. When I can't optimize any more that way, I'll maybe start looking at assembly.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Mar 16, 2014 4:19 am

One common problem to watch when using high-level languages is recursive functions. The MD has very little ram, and even less space tends to be reserved for the stack. Recursive functions can use a HELL of a lot of stack space.

As for state machines, those are good for simple things - unless you have something as simple as space invaders, the equations will have too many variables. However, I do recommend doing flow charts for the logic in your game to keep the structure in mind while writing the code.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Sun Mar 16, 2014 4:52 pm

For example: Donald in Maui Mallard using states. Bosses has more than ten states.
Ultimate Mortal Kombat 3: all fighters = TONS of states.
Image

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Mar 17, 2014 7:07 pm

You COULD break it into multiple state machines. That would keep them simple enough to solve. Again, do a flow chart for the game, then look for which spots in the flow chart could be turned into state machines. Note that using a state machine makes the game harder to debug as a single change in one input requires recalculating the state machine, changing the logic almost completely.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sat Mar 22, 2014 5:40 pm

Chilly Willy wrote:You COULD break it into multiple state machines. That would keep them simple enough to solve. Again, do a flow chart for the game, then look for which spots in the flow chart could be turned into state machines. Note that using a state machine makes the game harder to debug as a single change in one input requires recalculating the state machine, changing the logic almost completely.
That would depend on how you write your SM, Chilly. Table-Method is substantially easier to alter than the usual Switch-Statement/If..Else structure.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sat Mar 22, 2014 5:42 pm

Stef wrote:
KanedaFr wrote:;)
It makes me remember of a talk I had with Stef asking if he planned to port SGDK to asm. His answer was something like "I don't see the reason to do it, FOR NOW" (@stef, correct me if my memory bugs!)
Yeah it was almost that ;) ASM will be faster but SGDK is made for simplicity, readability and not performance it is why almost code is done in C. Still SGDK should be fast enough for common tasks and some parts are wrote in ASM when we need it. If a user really need the best performance he can write very optimized ASM methods to replace the SGDK ones.
Yes, I agree that it is important to have a Library available for Beginners. I have used your SGDK and I would ask you to generate Doxygen output for the internal Code too as it is a Library that is made for learning and for Beginners to refer to.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sat Mar 22, 2014 5:45 pm

KanedaFr wrote:;)

A little off topic but, I'm not telling you (or anyone) to use C, I'm just able to produce something in C while I'm only able the read 68000 asm.
It's how I am and I can't take the time to become an asm guru.
I'm more like code all I can using SGDK and re-code sensitive part in asm (like the uncompress func for ex which won't be as much powerful in C I think).
And using C, I know I won't ever make something as great as treasure game but, he!, even using asm, I won't ever make something as great as a treasure game because it's homebrew, not pro game we re talking about!
It could be interesting, on another post, to see which part should be written in asm (HInt is the 1st one).
It makes me remember of a talk I had with Stef asking if he planned to port SGDK to asm. His answer was something like "I don't see the reason to do it, FOR NOW" (@stef, correct me if my memory bugs!)


this post isn't about C vs ASM, it's about what to do in main loop, vint and hint. The several answers are valids for asm and C I think.
So it's up to every one to use it like it want, no ?
Sadly, I am not nor are you or anyone else 'telling you' to use Assembly - the situation merely requires you to write Assembly and to juggle Performance against Machine-Cycles.

You can see that you cannot get the necessary performance so easily writing in C for the V-Blank Routine so what other option do you have but not to use Assembly unless you choose not to use the V-Blank at all?

Am I misunderstanding something here?

How long have you been programming the MD for? You have been registered here for getting on 8 years - that's a long time and enough to become moderately able to write Assembly.

I've had just over a Year working on the MD myself.

No one but you can decide on your ambitions. Certainly, most of the Houses that wrote Games for the MD had good Programmers and most of us can only learn from them.
But let's make one thing clear: there is absolutely no difference between Commercial-Programmers and Homebrew-Programmers - most of them are in fact both, so again: only you can limit yourself and your ambitions. Treasure were human just like you and me so why let that stop you?

SGDK is made for Beginners and is not optimised as to that would require first of all rewriting the Code and secondly to be really optimised the situation that it was to be used in would be chosen and it would be better suited to a particular situation.

Since it is only for Beginners and not intended for optimised Games there is less need for it to be optimised and to conscientious with the 68K's and Z80's Machine-Cycles.

It may also be harder for the average Developer to understand the Assembly compared to the C but many will also want to learn 68K having looked at SGDK if only to write something faster and more efficient and better suited to their needs and indeed their Game - if that's what most of us are attempting to develop, right? :)

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sat Mar 22, 2014 6:01 pm

djcouchycouch wrote:So far, most of my problems with performance using C has been algorithmic. Spending time to rework a loop or refactor some heavy code has always bumped up my framerate in a nontrivial way. When I can't optimize any more that way, I'll maybe start looking at assembly.
Yep, check out profiling and look at the elements in your Algorithm, then work out their computational-weight to get a clear idea of how much each part costs.

Loop-Unrolling is a standard method to tackle the heavy costs of Iterators. Have a look at other Tips and in particular there's an Article published in BYTE from 1983 about programming 68K based Machines for some more Tips.

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Sat Mar 22, 2014 6:34 pm

MintyTheCat wrote:SGDK is made for Beginners and is not optimised as to that would require first of all rewriting the Code and secondly to be really optimised the situation that it was to be used in would be chosen and it would be better suited to a particular situation.

Since it is only for Beginners and not intended for optimised Games there is less need for it to be optimised and to conscientious with the 68K's and Z80's Machine-Cycles.
SGDK is definitely not for beginners. There are many beginners that have been stumped because they assumed Genesis development was easy. I see it as for those who don't know or don't want to work with assembly, like me.

I'd say SGDK is pretty performant. It's not assembly fast, but it's definitely not slow. You can do some pretty interesting things with it. It's just that nobody's shown how far it can be pushed, yet.
Last edited by djcouchycouch on Sat Mar 22, 2014 11:32 pm, edited 1 time in total.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sat Mar 22, 2014 8:14 pm

djcouchycouch wrote:
MintyTheCat wrote:SGDK is made for Beginners and is not optimised as to that would require first of all rewriting the Code and secondly to be really optimised the situation that it was to be used in would be chosen and it would be better suited to a particular situation.

Since it is only for Beginners and not intended for optimised Games there is less need for it to be optimised and to conscientious with the 68K's and Z80's Machine-Cycles.
SGDK is definitely not for beginners. There are many beginners that have been stumped because they assumed Genesis development was easy. I see it as for those who don't know or don't want to work with assembly, like me.

I'd say SGDK is pretty performant. It's not assembly fast, but it's not definitely not slow. You can do some pretty interesting things with it. It's just that nobody's shown how far it can be pushed, yet.
May be so, MD development is not the easiest but certainly not the hardest - try famicom development and then compare it to MD development.

But you are using a fixed Library and like it or not some decisions have already been made for you. There's substantially more hand-holding going on with SGDK and hence it's a Beginners' Library. I am not knocking it for being aimed at Beginners either as many younger People especially haven't even studied C in their Studies let alone Assembly.

It never will be 'assembly fast' as it's C, my man.

To get anywhere with any Platform one has to understand its Computer Architecture and to determine what type of Machine it is. Anyone with DSP experience or who has worked on anything 'Hardwarenah' can relate to that. C is merely something that is built on top of the native Machine. The question is only: how much do you need? If you can get away with C then by all means but don't kid yourself that you are getting the maximum performance, Couchy.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Mar 22, 2014 9:24 pm

MintyTheCat wrote:
Chilly Willy wrote:You COULD break it into multiple state machines. That would keep them simple enough to solve. Again, do a flow chart for the game, then look for which spots in the flow chart could be turned into state machines. Note that using a state machine makes the game harder to debug as a single change in one input requires recalculating the state machine, changing the logic almost completely.
That would depend on how you write your SM, Chilly. Table-Method is substantially easier to alter than the usual Switch-Statement/If..Else structure.
Ah, I see. You mean draw up the diagrams, convert them to tables, then DON'T solve the equations, just use the tables directly. Solving the equations minimizes the logic needed, eliminating tables and lots of if/then/switch/case structures, but does tie your SM to that particular set of inputs/outputs/transitions. I trained in hardware (only took programming when I needed the easy credits), so I naturally think "solve the equations" when I hear "state machine". :D

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sat Mar 22, 2014 10:28 pm

Chilly Willy wrote:
MintyTheCat wrote:
Chilly Willy wrote:You COULD break it into multiple state machines. That would keep them simple enough to solve. Again, do a flow chart for the game, then look for which spots in the flow chart could be turned into state machines. Note that using a state machine makes the game harder to debug as a single change in one input requires recalculating the state machine, changing the logic almost completely.
That would depend on how you write your SM, Chilly. Table-Method is substantially easier to alter than the usual Switch-Statement/If..Else structure.
Ah, I see. You mean draw up the diagrams, convert them to tables, then DON'T solve the equations, just use the tables directly. Solving the equations minimizes the logic needed, eliminating tables and lots of if/then/switch/case structures, but does tie your SM to that particular set of inputs/outputs/transitions. I trained in hardware (only took programming when I needed the easy credits), so I naturally think "solve the equations" when I hear "state machine". :D
No, what is meant by the SM Table-Method is a Table of States and their Transitions are Indices into each Table.

Here's a quick Example that I just found here:

http://www.gedan.net/2008/09/08/finite- ... mentation/

Generally speaking the Table-Method is a lot easier to handle than the If..Else/Switch Method and that Method becomes unwieldy pretty quickly if you have more than a couple of States and Transitions.

Tbh I have not done much VHDL but I am learning it once again. I only did a did at University but it most certainly helps the Embedded Developer to appreciate 'just what's on the other side' for when the Hardware does something 'a bit weird'.

Cheers,

Minty.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Mar 23, 2014 6:27 pm

MintyTheCat wrote:No, what is meant by the SM Table-Method is a Table of States and their Transitions are Indices into each Table.

Here's a quick Example that I just found here:

http://www.gedan.net/2008/09/08/finite- ... mentation/
Yes, yes, I know... and if you were a hardware engineer, you'd take that table in the example and turn it into boolean equations that generated all outputs without the need for a table or processor doing if/then/switch. Set up a grey code table of the inputs and outputs, circle the factors, and solve the equations. Pretty standard SM problem solving...
8)

Post Reply