How to build a self-running demo?

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
Miquel
Very interested
Posts: 177
Joined: Sat Jul 30, 2016 12:33 am

How to build a self-running demo?

Post by Miquel » Tue Sep 06, 2016 4:33 pm

Do you remember old games, where if you don't press start in the title the game starts but plays by itself?
How is that accomplished?

Right now I'm thinking of an emulator and a pc program that captures keys presses, then pack all this data into more compact form and inject directly to the input of player(s).

That's a bit complicated, a week work, do you know a faster, better way of doing it in MD/Genesis?
Confused? Just ask!

User avatar
TmEE co.(TM)
Very interested
Posts: 2285
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: How to build a self-running demo?

Post by TmEE co.(TM) » Tue Sep 06, 2016 5:07 pm

Start your game, record all the input and use that as input for the demo sessions.

EDIT: You can save the keypresse is SRAM and use the SRM file from emulator to get the data to include in your ROM.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Miquel
Very interested
Posts: 177
Joined: Sat Jul 30, 2016 12:33 am

Re: How to build a self-running demo?

Post by Miquel » Tue Sep 06, 2016 8:06 pm

TmEE co.(TM) following your suggestion I found that "Gens Kmod" seems to be the better option, in my case, for recording input.

From the help files:
-----------------------------------
- GMC File Description -
-----------------------------------
uchar Format
//what is on the GMC File, add the needed values
//0x01 -> player1 input
//0x02 -> player2 input
//0x04 -> boutons 6 added
//0x80 -> compressed
uchar reserved[0x0E]
//futur use
uchar data

if compressed
the first char is the number of frames of the input
the second char is the first input (if needed)
the third char is the second input (if needed)
the 4th char is the third input (if needed)
else
the first char is the first input (if needed)
the second char is the second input (if needed)
the thirs char is the third input (if needed)
So far I have discovered that reserved size is 15, not 14, and a '1' means no input, so 0xFF is no button pressed.

I will need some kind of end of record mark, and erase that reserved field,... every thing else is fine.
Confused? Just ask!

User avatar
KanedaFr
Administrateur
Posts: 1110
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Re: How to build a self-running demo?

Post by KanedaFr » Tue Sep 06, 2016 9:08 pm

I was about to talk about it but I'm very happy you found it yourself!

I made this feature yearrrrs ago, while working a canceled-coming-soon game which required the demo mode.
I know that, at some times, I made a demo to help anyone use it ( a basic player ) but it seems I lost it :(


I never updated it since noone showed some kind of interest at that time.
If you see bugs or way to improve it, i'll be more that happy to fix it.

User avatar
Natsumi
Very interested
Posts: 81
Joined: Mon Oct 05, 2015 3:00 pm
Location: 0x0
Contact:

Re: How to build a self-running demo?

Post by Natsumi » Wed Sep 07, 2016 5:48 am

oftentimes games would just override the controller input with data from a file. Games need to be programmed with this in mind, however, so the game correctly responds to held/pressed states and keeps in sync! The way Sonic 1 is precisely this, and the buttons are (thought to) be recorded via unused subroutine, and dumped somehow. They also likely used assembler option for specific demo, as ending demos dont start from level start.

Miquel
Very interested
Posts: 177
Joined: Sat Jul 30, 2016 12:33 am

Re: How to build a self-running demo?

Post by Miquel » Wed Sep 07, 2016 8:08 pm

Already done, thanks to gens kmod (and you Kaneda!) it was a piece of cake.
KanedaFr wrote:I was about to talk about it but I'm very happy you found it yourself!

I made this feature yearrrrs ago, while working a canceled-coming-soon game which required the demo mode.
I know that, at some times, I made a demo to help anyone use it ( a basic player ) but it seems I lost it :(
I don't really need any demo to show the player how to manage the game, but it feels a lot more complete with demos. It shows off better.
KanedaFr wrote:I never updated it since noone showed some kind of interest at that time.
If you see bugs or way to improve it, i'll be more that happy to fix it.
So far I have found:
- Header is 16bytes, so reserved size is 15. (in the doc it says it's 14)
- That's just a convention, but in this case '0' means on while '1' means off. Usually it works on reverse: we are used to do something like "value & flag" in C.
- A, B and C button values reside in different bit compared to hardware. Up, down, left, right and start are ok.
- A keyboard shortcut will be definitely a lot better, if not, there are an unknown amount of frames added while you move the mouse.
- Perhaps a mark of end of stream will be nice, I use 0 frames to do that (I think that this value is impossible other way)
Natsumi wrote:oftentimes games would just override the controller input with data from a file. Games need to be programmed with this in mind, however, so the game correctly responds to held/pressed states and keeps in sync! The way Sonic 1 is precisely this, and the buttons are (thought to) be recorded via unused subroutine, and dumped somehow.
You can't override (completly) input since you have to still respond to a botton press to stop the demo. But, yes is just that: override input, every thing already done works the same. In fact, as I said, is quite esay, it doesn't change too much code.
Natsumi wrote:They also likely used assembler option for specific demo, as ending demos dont start from level start.
If your game don't load dynamically data, that's not a big deal, just set x & y. On the contrary, if you really load data in game, you can reuse a save point, and readjust a little bit x & y, or indeed you have to program a new entry to the level with all the dynamic data loaded. I don't like that last idea since is not changes friendly, as alternative you can search all the changes up to this point and commit, that sounds better.
Confused? Just ask!

User avatar
Natsumi
Very interested
Posts: 81
Joined: Mon Oct 05, 2015 3:00 pm
Location: 0x0
Contact:

Re: How to build a self-running demo?

Post by Natsumi » Thu Sep 08, 2016 11:19 am

To be more specific, Sonic 1 has duplicate vaöues for button presses; one for players (Sonic), and one for controller (Ctrl 1). During demo, instead of reading input from ctrl 1 for Sonic, it reads from ROM. Start button is checked from ctrl 1 so it will still work (and by extension a demo cannot end itself prematurely, although it could be coded to).

The ending demos really just create a fake checkpoint, and use the games code to put Sonic at any point in the level. Only trouble is that if there are layout changes these checkpoints will be broken. I would believe this is something they added really late.

User avatar
Sik
Very interested
Posts: 591
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: How to build a self-running demo?

Post by Sik » Fri Sep 09, 2016 6:56 am

And that backfired because if you hold down the jump buttons then Sonic won't jump. It's checking those against the previous real input. Probably the easiest way is to actually replace the current controller input, but leaving the Start button untouched (i.e. replace all other buttons). Works for computer opponents too =P
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 177
Joined: Sat Jul 30, 2016 12:33 am

Re: How to build a self-running demo?

Post by Miquel » Fri Sep 09, 2016 6:59 pm

Natsumi, if fact there are 3 ways of controlling player in games like sonic, we have to add a 3rd option: when in normal gaming control is taken from player, usually to reach some point. In Sonic is used for example to get out of the current level.

So doing it is quite easy but requires some thought. To don't be caught in race conditions my recommendation is to duplicate data (or maybe triplicate) until last moment where is decided which data is going to be used.
Sik wrote:And that backfired because if you hold down the jump buttons then Sonic won't jump. It's checking those against the previous real input.
Probably the easiest way is to actually replace the current controller input, but leaving the Start button untouched (i.e. replace all other buttons). Works for computer opponents too =P
You are right! I first tried with what was on hand, and doesn't happened as you said, then I thought perhaps it was corrected on after revisions so I get first revision of the rom, and there it was: Sonic can't jump if jump buttons are pressed.

Even so, is well programed because the game doesn't go to a "continue?" kind of screen, it just ends demo.
Last edited by Miquel on Fri Sep 09, 2016 8:09 pm, edited 1 time in total.
Confused? Just ask!

User avatar
Natsumi
Very interested
Posts: 81
Joined: Mon Oct 05, 2015 3:00 pm
Location: 0x0
Contact:

Re: How to build a self-running demo?

Post by Natsumi » Fri Sep 09, 2016 8:06 pm

Sik; You could also emulate pressed/held states on demo code you know

User avatar
Sik
Very interested
Posts: 591
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: How to build a self-running demo?

Post by Sik » Sat Sep 10, 2016 3:08 pm

The problem wasn't that but that having a duplicate variable made it easy to overlook that detail. The least stuff you have to touch (and let it spread its effects everywhere else on its own), the better.
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 177
Joined: Sat Jul 30, 2016 12:33 am

Re: How to build a self-running demo?

Post by Miquel » Wed Sep 28, 2016 3:16 pm

It was badly rephrased on my part. I meant that since there are several inputs, instead of trying to combine them, on later stages, into a single input trying to guess how is gonna work later, just store them into several variables with the same meaning (or structure) but different content (data) as soon as possible.

Anyway there is a lot of intermediate result stored into memory in gaming (I recon that is not exactly the same as duplicate). It doesn't follow quite good the rules of encapsulation despite we like them so much.
Confused? Just ask!

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests