blueMSX again, big problem (recording)

Página 4/5
1 | 2 | 3 | | 5

Por flyguille

Prophet (3028)

Imagen del flyguille

03-04-2010, 21:59

I thinks, about the blueMSX replay problem, as you use VISTAS, maybe it is a timming problem, maybe your hardware is slowdowing the input replaying, or emulation, so as speeds don't match, maybe it is a problem of synchronizing.

Por JohnHassink

Ambassador (5595)

Imagen del JohnHassink

03-04-2010, 23:43

@ manuel and FiXato: thanks again, tell you what, I'll first struggle with openMSX some more, and when, only when, I really can't figure it out by myself, I'll go harass you guys about it. Smile

@ flyguille: that is a very good suggestion! I will reproduce the recording/rendering situations on a Windows XP system, and see what happens. Thanks to you too!

Por Manuel

Ascended (18384)

Imagen del Manuel

04-04-2010, 13:47

flyguille, that shouldn't matter, really. The times are in the MSX universe, not in the host universe. (At least, that's the case for openMSX, and I'm quite sure something similar will be in blueMSX.)

DemonSeed: anyway, we're standby for you Smile

Por FiXato

Scribe (1726)

Imagen del FiXato

04-04-2010, 13:52

DemonSeed, if you are interested, I could hold a Skype session or something with you, see if I can walk you through the most common features Smile
Though, I have to set up openMSX and Catapult under Windows first, as I use Mac OS X primarily Wink

Por flyguille

Prophet (3028)

Imagen del flyguille

04-04-2010, 21:48

flyguille, that shouldn't matter, really. The times are in the MSX universe, not in the host universe. (At least, that's the case for openMSX, and I'm quite sure something similar will be in blueMSX.)

DemonSeed: anyway, we're standby for you Smile

ohhh, and how the hell you do that? I means......

The game/soft running can be anything ok?

What you do? recording INPUTs like keyboard? & joystick & mouse? I do not understand because........

how often or when you take a record?

Because if we, by example, records a entire keyb map in every, says, VDP interrupt

what if the game is not going on VDP interrupt rythm? maybe it is a spectrum conversion or a hell heavy game that takes more than just one VDP interrupt....

so?, maybe you gets SWAPs of keyb records on playback.

Now thinks that recording each vdp interrupt does not works for every game

Lets says, record a keyb stat in every 10000# cpu command execution, that will be like 100 records per second? ok far enoght?, what if just one records is swapped ?

Now, lets imagine, that each time the software does a keyb reading, you will playback a keyb stats from file.... what? synching that way?, what if the gameplay don't move enemies, animation in the same rythm that it take readings from inputs?, because recording on readings like triggers, is like supposing that gameplay routine is 1 input reading + reaction + animation + what happens. (well most of soft is that way), but it is not a perfect method.

What if enemies has ramdon behavior ? recording just inputs is enought? nahh, on playback you will gets ramdon results every replay.

I thinks the best method is the save of all vdp/psg stats..... if you just want a video of your game play, now if you want to re-do parts of the gameplay, like doing "the perfect game" vid, you needs to save alll RAM/CPU .... devices, all.

Por wouter_

Champion (470)

Imagen del wouter_

04-04-2010, 22:39

I can only comment on how record/replay is implemented in openMSX, but I suppose it's very similar in blueMSX.

What you do? recording INPUTs like keyboard? & joystick & mouse? I do not understand because........

how often or when you take a record?

Because if we, by example, records a entire keyb map in every, says, VDP interrupt

what if the game is not going on VDP interrupt rythm? maybe it is a spectrum conversion or a hell heavy game that takes more than just one VDP interrupt....

We don't record the complete MSX keyboard state (and joystick, mouse, disk images swaps, ...) at some fixed time interval. Instead we only record changes in the input state (_all_ input state). So for example when the user presses or releases a key, we record this event and annotate it with the exact time in MSX time (e.g. measured in Z80 clock cycles). On replay we uses this time to give exactly the same input at exactly the same time to the MSX. Note that we don't need to know when or how often (or if at all) the MSX actually uses the keyboard state. Also note that because only difference are recorded, the whole recording is very compact.

Now, lets imagine, that each time the software does a keyb reading, you will playback a keyb stats from file.... what? synching that way?, what if the gameplay don't move enemies, animation in the same rythm that it take readings from inputs?, because recording on readings like triggers, is like supposing that gameplay routine is 1 input reading + reaction + animation + what happens. (well most of soft is that way), but it is not a perfect method.

What if enemies has ramdon behavior ? recording just inputs is enought? nahh, on playback you will gets ramdon results every replay.

Random behavior doesn't really exist in computers. If the replay starts from the _exact_ same state and all input is _exactly_ the same as in the original play, then the replay will show exactly the same 'random' behavior.

Por flyguille

Prophet (3028)

Imagen del flyguille

04-04-2010, 23:28

a random number generator, can be randomized, by example, taking a reading to the RTC and to use its value as SEED. That is very common on PC-WORLD. and GWBASIC do that, but I do not remembe if the RAMDOMIZE command at MSX-BASIC do it that way.

So, every runtime it has a seeds different.

mmmm.... i remember now, ramdomize in msx-basic is taking a reading to the bios count-up variable that ticks in every vdp int? I am right?

In that way, running the game a bit after, wil make a difference. But as everybody uses ROM image, I thinks there is no problem.

Por Manuel

Ascended (18384)

Imagen del Manuel

04-04-2010, 23:48

flyguille: there is no real source of randomness in an MSX. When doing replays, we recreate exactly the same situation (including the RTC), so the random number generator will give exactly the same values. But this is basically what Wouter already said Smile

EDIT: oh, in Wouter's latest comment it's actually even more the same as what he is saying Tongue (so never mind this comment)

Por wouter_

Champion (470)

Imagen del wouter_

04-04-2010, 23:48

(In openMSX) the RTC state is part of the replay state, during replay the MSX will read the same values from the RTC as in the original play. So it should work fine even if the game uses the RTC as a random source.

Por flyguille

Prophet (3028)

Imagen del flyguille

05-04-2010, 00:34

well, the aseveration of "msx has not random sources", maybe it is true with ROM cartridges, and about thinking in a standard method.

But the aseveration is not 100% true. Atleast in REAL msxs.

You see, that talking about disk accesses, there is a random waiting, that can do the wait long or short.

What does the length of the wait?, the position of the disk when it starts spinning, how far/near is the INDEX hole from the hole detector, that things will slowdown a bit, just a bit, the start of disk accesses.

It is measured in VDP ints, just use the bios variable. (it can be done? or disk bios dissables the int mmmhhh...i do not remember if in that part it does or just after the ready signal?.

what drop to the garbage the idea

Página 4/5
1 | 2 | 3 | | 5