It is currently Thu Mar 28, 2024 10:19 pm


All times are UTC [ DST ]




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject:
PostPosted: Thu Mar 21, 2002 9:54 am 
Grizzled Veteran
Grizzled Veteran

Joined: Wed Nov 07, 2001 1:00 am
Posts: 52
Location: London UK
OK. This is now going to be my official topic for (working name) the 'LD Construction set'.
I will post my progress here, and expect comments and suggestions here too.

I want to stay away from altering ANY existing Daphne code, so that I can develop this on my own without interfering with any existing Daphne development, then just hand over some finished code for inclusion in Daphne when I have a working release version for it. The only Change in the existing Daphne code will be the inclusion of a NEW game in the list, and that should be simple enough to do :smile:

I hope that this is finally my chance to give something back to Daphne for all the Joy brought to me by the other developers.


Top
Offline Profile  
 
 Post subject:
PostPosted: Mon Mar 25, 2002 5:42 pm 
Grizzled Veteran
Grizzled Veteran

Joined: Tue Oct 02, 2001 1:00 am
Posts: 60
Location: Columbus, OH
Are you looking to produce a generic LD game engine, or is it more of a LD game wrapper for which you write a custom game module in C? The difference, to me, is that the first approach might not require the ROMs directly, whereas the second surely would. In the first case, one would describe in a meta-language, the sequence of turns, percentage chances, required/optional controller moves, etc. The engine would digest them and process them as a native file. In the second case, there might be a processor-level code emulator that was shared amongst games with similar innards, then a game-specific module that would depend on the arcade-CPU-emulator, but send display/LD control events up to the LD game engine.

The first approach would only really be useful for those games like DL and SA that have been throughly disassembled and documented. In fact, they could probably be mostly done by a Perl script that reached into the ROMs and digested the existing tables that the original arcade game itself uses. Throw in some attract-mode code and you'd have a game very close to the original. You could even throw the DLE and SAE "upgrade" ROMs at them and get the desired results. This is kinda like what we did in the old days with the Scott Adams and Infocom adventures - wrote our own engines to use the original data files.

The second approach is more like a modular Daphne - take a Z-80 or 6502 or 68000 (American Laser Games) emulator, turn it into a library, then attach a DL-specific, or SA-specific, or Mad Dog McCree-specific module that knows what the I/O looks like to translate the direct accesses into events that get passed up to the engine as LD-seek or MPEG-display events. Presumably, joystick/keyboard events would be handled at the engine level and passed down as I/O events, a-la Amiga's Intuition loop - events are injected into a queue by whomever, and removed by a different whomever, so that nobody has to know details of the other - just that part A produces events generated by the player pushing on stuff and part B produces display events generated by the code in the ROMs detecting certain conditions or lack of player-movement events. In this model, A probably consumes events inserted by B and vice versa.

Adding a "real" scoreboard for DL and SA (one of my personal favorite things about Daphne) is a matter of writing a scoring event consumer/client that sits in the queue after B sends scoring events, but before A consumes them. This scoreboard client could either remove events from the queue or leave them in place so that you would see scores both on the PCs screen or not. In fact, this scoreboard client could remove the event from B and insert its own event so that the engine could know that there _is_ a real scoreboard out there and to not worry about displaying score data if the player is using an MPEG file, for example.

Using an input event loop in this manner allows you to not have to code for special cases - you set up a chain of events, and as long as you see the expected events, it doesn't matter how they go t there or not - easy to describe, easy to document, easy to test. Lots fewer "if/else" clauses, too. Less work to extend functionality.

Comments?

-ethan

P.S. - since there's LD-drivers for the Sony LDP-1500 for AmigaVision, I wonder how hard it would be to write a DL emulator based on the event chain from the DL ROMs... I could do it, but then who could run it? :wink:



<font size=-1>[ This Message was edited by: Ethan on 2002-03-25 09:48 ]</font>


Top
Offline Profile  
 
 Post subject:
PostPosted: Wed Mar 27, 2002 1:23 pm 
Grizzled Veteran
Grizzled Veteran

Joined: Wed Nov 07, 2001 1:00 am
Posts: 52
Location: London UK
Thanks for the LONG reply! But most of that has already been explained in my posts on the DLP.
I dont wanna repeat myself so go search the DLP archives for my thread about this. That should explain most of it.

Ive done lots of coding already and see a few issues with my idea so far, but should be able to get a simple version working assuming it compiles within daphne.

The main prob is I dont HAVE a compiler on my PC atm, so its all done without testing...

As soon as ive done a test compile ill send it to Matt to try, then we can let people know what is happening. Sorry to be so vague atm.


Top
Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net