21 replies to this topic

[DZ-Jay]

Hello:

I'm planning on working to update the P-Machinery engine/framework to fix some bugs, be more consistent in its nomenclature, and add new features.

Among the things I was thinking are needed are:

• More variety of input decoders, such as support for two controllers and even including an ECS keyboard decoder.
  
• A simpler abstraction of printable text functionality that will also support custom GRAM font sets without much effort.
  
• Built-in support for music using Arnauld's tracker (I'll ask him first to make sure it's OK).
  
• A basic Sprite Driver and programming model that is flexible and easy to use.

I also was thinking of writing simple game to accompany a tutorial on how to use P-Machinery in practical situations. Perhaps a version of "Tag-Along-Todd" built entirely in P-Machinery.

Regarding the Sprite Driver, what I want to do is offer a flexible programming model that abstracts all the hard stuff of handling sprites, such as limited access during VBLANK, collision detection, variable velocity, and animations. Something like simple data structures that keeps the state of the objects and are accessible at all times, and then blasted into the STIC registers and cycle GRAM as needed.

Does anybody have any additional suggestions or comments?

P-Machinery is intended not only to make it simpler for newcomers to get acquainted with the platform, but to actually ease the development of real games. It should offer facilities to make simple stuff very easy and almost automatic, and hard stuff at least possible.

-dZ.

[intvnut]

As always, you're welcome to incorporate any and all of the library functions I've written and put into the public domain. I've got code for reading the ECS keyboard and synth, for example, that you can take any time.

[GroovyBee]

I'm not familiar with your framework but I think continuing your tutorial series would be good. If we could have a "Programming Intellivision for newbies" as a sub forum of the Inty programming forum to go along with it then it could all be contained in one place. That would make your life easier to update the required files on AA as and when required.

[DZ-Jay]

intvnut, on Thu Feb 9, 2012 1:25 PM, said:

As always, you're welcome to incorporate any and all of the library functions I've written and put into the public domain. I've got code for reading the ECS keyboard and synth, for example, that you can take any time.

Thanks, I'll definitely make use of it, since most of P-Machinery already relies in the SDK-1600. The framework is mostly wrappers around that.

-dZ.

[vprette]

What can I say?
I started from zero knowledge with P-machinery and ending in some running rom with music in 2 weeks!
for a newbye is a precious tool, my guess is music traker must be integrated for sure

[catsfolly]

It looks like a well designed system overall.

One thing that comes to mind:
I generally try and assemble my program, and then if it reports errors or warnings I open the listing file and search for errors and warnings so I can fix them in the source code. (Is there a better way to do this?).

Anyway, it seems like in many places in the pmachinery there are comments that say "warning, warning, danger will robinson",
or some such thing, so when I search for warnings I find these statements. Would it be possible to use another word besides "warning"?

catsfolly

[DZ-Jay]

catsfolly, on Sat Feb 11, 2012 4:42 AM, said:

It looks like a well designed system overall.

One thing that comes to mind:
I generally try and assemble my program, and then if it reports errors or warnings I open the listing file and search for errors and warnings so I can fix them in the source code. (Is there a better way to do this?).

Not that I know of. Alas, there is no integrated debugger or IDE, if that's what you're looking for. The listing file is the standard output of the assembler.

catsfolly, on Sat Feb 11, 2012 4:42 AM, said:

Anyway, it seems like in many places in the pmachinery there are comments that say "warning, warning, danger will robinson",
or some such thing, so when I search for warnings I find these statements. Would it be possible to use another word besides "warning"?

catsfolly

Oh, I know exactly what you mean, and it does annoy me when I have to search for warning. I just haven't gotten around to change it.

There are I think three places preceded with

;; ======================================================================== ;;
;;                                                                          ;;
;;  ----------------------------------------------------------------------- ;;
;;  WARNING! ACHTUNG! WARNING! ACHTUNG! WARNING! ACHTUNG! WARNING! ACHTUNG! ;;
;;  ----------------------------------------------------------------------- ;;
;;                                                                          ;;
;;  The boot-up sequence, including ISR handlers, are arranged in a         ;;
;;  particular way.  This is by design.  Changing any step may impact the   ;;
;;  overall state of the machine, causing unexpected results.               ;;
;;                                                                          ;;
;;        DO NOT change unless you really know what you are doing!          ;;
;; ======================================================================== ;;

At the time I thought it was cute to show it like that, but it does get in the way of finding real warnings. I'll change it to "ATTENTION! ACHTUNG!" which is actually the correct correspondence.

-dZ.

[DZ-Jay]

intvnut, on Thu Feb 9, 2012 1:25 PM, said:

As always, you're welcome to incorporate any and all of the library functions I've written and put into the public domain. I've got code for reading the ECS keyboard and synth, for example, that you can take any time.

Thanks. I also sent a curtesy request to Arnauld to include his tracker in P-Machinery, but never received a response. The copy I have states that it was released into the public domain, which I guess makes it perfectly fine to re-destribute; but I would like to have his express blessing like yours.

-dZ.

[DZ-Jay]

DZ-Jay, on Sat Feb 11, 2012 7:23 AM, said:

catsfolly, on Sat Feb 11, 2012 4:42 AM, said:

It looks like a well designed system overall.

One thing that comes to mind:
I generally try and assemble my program, and then if it reports errors or warnings I open the listing file and search for errors and warnings so I can fix them in the source code. (Is there a better way to do this?).

Not that I know of. Alas, there is no integrated debugger or IDE, if that's what you're looking for. The listing file is the standard output of the assembler.

catsfolly, on Sat Feb 11, 2012 4:42 AM, said:

Anyway, it seems like in many places in the pmachinery there are comments that say "warning, warning, danger will robinson",
or some such thing, so when I search for warnings I find these statements. Would it be possible to use another word besides "warning"?

catsfolly

Oh, I know exactly what you mean, and it does annoy me when I have to search for warning. I just haven't gotten around to change it.

There are I think three places preceded with

;; ======================================================================== ;;
;;																		  ;;
;;  ----------------------------------------------------------------------- ;;
;;  WARNING! ACHTUNG! WARNING! ACHTUNG! WARNING! ACHTUNG! WARNING! ACHTUNG! ;;
;;  ----------------------------------------------------------------------- ;;
;;																		  ;;
;;  The boot-up sequence, including ISR handlers, are arranged in a		 ;;
;;  particular way.  This is by design.  Changing any step may impact the   ;;
;;  overall state of the machine, causing unexpected results.			   ;;
;;																		  ;;
;;		DO NOT change unless you really know what you are doing!		  ;;
;; ======================================================================== ;;

At the time I thought it was cute to show it like that, but it does get in the way of finding real warnings. I'll change it to "ATTENTION! ACHTUNG!" which is actually the correct correspondence.

-dZ.

Another thing you can do is set the listing output to "code." this will remove suppress any comments and macro expansion work and include only the assembled code. However, not that by suppressing comments and macros it limits the context of the code shown.

-dZ.

[DZ-Jay]

catsfolly, on Sat Feb 11, 2012 4:42 AM, said:

It looks like a well designed system overall.

Thanks. Along with the basic Sprite Driver, I will include a version of my "Auto-Pilot" engine for scripting sprite interactions. Right now, it's rather hard-wired for the sprite records of Christmas Carol, but once I implement the new sprite model I will generalize it.

I originally wrote it to automate Pac-Man's Ghost movements during states where the AI is not used (like when they are released from their cages or when they are eaten). It eventually grew into a more flexible mechanism to script the Christmas Carol introduction sequences.

The Auto-Pilot offers a set of commands that you can put together in a "script" sequence, and assign it to a sprite. Then the sequence will run until the end and relinquish control to the sprite driver. Each sprite can have its own Auto-Pilot script.

Here's an example of the first introduction sequence from Christmas Carol:

;;==========================================================================;;
;; Title:       Auto-Pilot Scripts                                          ;;
;; By:          DZ-Jay                                                      ;;
;; Description: Data structures for Auto-Pilot scripts.                     ;;
;;                                                                          ;;
;; Copyright 2010-2011, James Pujals (DZ-Jay), <dz-game@techunlimited.net>. ;;
;;==========================================================================;;

; ===================================================================
APS_ISEQ_1      PROC

                ; +---------------------------+-----------------------+-------------------+
                ; |     Command:              | Param1:               | Param2:           |
                ; +---------------------------+-----------------------+-------------------+
@@Elf:          DECLE   AP_CMD.SetFlag,         SPR_FLAG.Active,        AP_NONE

                DECLE   AP_CMD.SetSpeed,        HEX_RATE(45),           AP_NONE
                DECLE   AP_CMD.MoveToX,         (TILE_SIZE * 19),       AP_NONE

                DECLE   AP_CMD.ClearFlag,       SPR_FLAG.Active,        AP_NONE
                DECLE   AP_CMD.Stop,            INTRO_SEQ_1.EndElf,     AP_NONE

                ; +---------------------------+-----------------------+-------------------+
                ; |     Command:              | Param1:               | Param2:           |
                ; +---------------------------+-----------------------+-------------------+
@@Ghost:        DECLE   AP_CMD.SetFlag,         SPR_FLAG.Active,        AP_NONE
                DECLE   AP_CMD.SetVisib,        AP_SHOW,                MOB.mGhost

                DECLE   AP_CMD.SetSpeed,        HEX_RATE(70),           AP_NONE
                DECLE   AP_CMD.MoveToX,         (TILE_SIZE * 11),       AP_NONE

                DECLE   AP_CMD.Delay,           20,                     AP_NONE
                DECLE   AP_CMD.SetDir,          SPR_DIR.Left,           AP_NONE
                DECLE   AP_CMD.Delay,           40,                     AP_NONE

                DECLE   AP_CMD.SetDir,          SPR_DIR.Right,          AP_NONE
                DECLE   AP_CMD.Delay,           40,                     AP_NONE

                DECLE   AP_CMD.SetDir,          SPR_DIR.Left,           AP_NONE
                DECLE   AP_CMD.Delay,           14,                     AP_NONE

                DECLE   AP_CMD.SetDir,          SPR_DIR.Right,          AP_NONE
                DECLE   AP_CMD.Delay,           30,                     AP_NONE

                DECLE   AP_CMD.SetSpeed,        HEX_RATE(80),           AP_NONE
                DECLE   AP_CMD.MoveToX,         (TILE_SIZE * 19),       AP_NONE

                DECLE   AP_CMD.ClearFlag,       SPR_FLAG.Active,        AP_NONE
                DECLE   AP_CMD.SetVisib,        AP_HIDE,                MOB.mGhost
                DECLE   AP_CMD.Stop,            INTRO_SEQ_1.Done,       AP_NONE
                ENDP
; ===================================================================

There are two scripts there, one for the Carol (@@Elf) and one for the Ghost (@@Ghost). The Elf just walks from one end of the stage to the other. The Ghost moves to the center of the stage, stops, looks in various directions, then goes to the end of the stage.

The command "Stop" accepts a parameter pointing to a call-back. I used this at the end of the Elf script to engage the Ghost script. That way, one sprite follows the other.

The Auto-Pilot engine can pilot multiple sprites simultaneously, too.

-dZ.

Edited by DZ-Jay, Sat Feb 11, 2012 9:59 AM.

[vprette]

DZ-Jay, on Sat Feb 11, 2012 9:59 AM, said:

The Auto-Pilot engine can pilot multiple sprites simultaneously, too.

-dZ.

look perfect for a space invaders style game (that is my second project that I would like to start in few time))

Edited by vprette, Sat Feb 11, 2012 2:16 PM.

[vprette]

My second project I'm thinking about will be called When Empires Collide and it's a galaga clone.
being Galaga complex in terms of animation, I rather start it as a space invader basic shooter, and introduce step by step some better feature, surely a level with one only big enemy ship to be destroied... the dynamic seems to me simple and I guess p-machinery already have what is needed for such a project, am I right?

the only regret here is that I do not see any use of ECS for this kind of game, and I'm motivated to work on ECS games more than standard intv

Edited by vprette, Sun Feb 12, 2012 9:47 AM.

[DZ-Jay]

vprette, on Sun Feb 12, 2012 9:45 AM, said:

My second project I'm thinking about will be called When Empires Collide and it's a galaga clone.
being Galaga complex in terms of animation, I rather start it as a space invader basic shooter, and introduce step by step some better feature, surely a level with one only big enemy ship to be destroied... the dynamic seems to me simple and I guess p-machinery already have what is needed for such a project, am I right?

the only regret here is that I do not see any use of ECS for this kind of game, and I'm motivated to work on ECS games more than standard intv

Valter,

P-Machinery will make it easier to put the game together, but currently it has no special support for sprites. As I mentioned, I will work on a sprite driver for P-Machinery soon, so even that will be covered.

Keep in mind that P-Machinery may not be suitable for all games. Some games, especially ambitious projects that drive the hardware capabilities to their limits, require a level of tweaking and micro-optimization that P-Machinery won't be able to offer with its generalized structure.

And I would say that, although those kind of games are very good and raise the value of the console, they are so hard to program that they either take too long to produce or seldom get finished. If you consider that a game can still be good and fun without stretching the limits of the hardware, then a generalized framework like P-Machinery should suffice for most of them.

In the future, I plan to do both: P-Machinery games mostly, and once in a long while an original game that breaks away from the capabilities of P-Machinery.

As for your Galaga clone, the animation is really not a big deal (I think it's like 2 or 3 frames per monster only). The complexity is in the flight patterns. However, even that can be easily done by defining the patterns as a series of direction changes in time. The "Auto-Pilot" I was talking about before will not really serve this purpose, for I believe it's overkill for it. Also, the Auto-Pilot is intended more for autonomous and non-interactive sequences, like intermissions and introductions.

Regarding the ECS, it's hard to take advantage of it, except for the extra sound card and expanded RAM. I can't think of many games I'd like to play on a retro console that involve a keyboard--especially a stupid, chiclet-sized, unreliable keyboard like the one that comes with the ECS.

Perhaps the Intellivision community would profit from having a series of "Interactive Fiction" games. We could work on a generalized engine for simple text or graphics adventures (a la SCUMM, or SGI) to facilitate making ECS games that require the keyboard. Nothing spectacular like the Z-Machine used by Infocom, but at least simple adventures driven by either point-and-click commands (like newer SGI) or "VERB NOUN" command-line interface (like old SGI).

Something like the classic "Space Quest" or "King's Quest" series should be very much possible on the Intellivision.

-dZ.

Edited by DZ-Jay, Sun Feb 12, 2012 10:32 AM.

[vprette]

DZ-Jay, on Sun Feb 12, 2012 10:21 AM, said:

vprette, on Sun Feb 12, 2012 9:45 AM, said:

My second project I'm thinking about will be called When Empires Collide and it's a galaga clone.
being Galaga complex in terms of animation, I rather start it as a space invader basic shooter, and introduce step by step some better feature, surely a level with one only big enemy ship to be destroied... the dynamic seems to me simple and I guess p-machinery already have what is needed for such a project, am I right?

the only regret here is that I do not see any use of ECS for this kind of game, and I'm motivated to work on ECS games more than standard intv

Valter,

P-Machinery will make it easier to put the game together, but currently it has no special support for sprites. As I mentioned, I will work on a sprite driver for P-Machinery soon, so even that will be covered.

Keep in mind that P-Machinery may not be suitable for all games. Some games, especially ambitious projects that drive the hardware capabilities to their limits, require a level of tweaking and micro-optimization that P-Machinery won't be able to offer with its generalized structure.

And I would say that, although those kind of games are very good and raise the value of the console, they are so hard to program that they either take too long to produce or seldom get finished. If you consider that a game can still be good and fun without stretching the limits of the hardware, then a generalized framework like P-Machinery should suffice for most of them.

In the future, I plan to do both: P-Machinery games mostly, and once in a long while an original game that breaks away from the capabilities of P-Machinery.

As for your Galaga clone, the animation is really not a big deal (I think it's like 2 or 3 frames per monster only). The complexity is in the flight patterns. However, even that can be easily done by defining the patterns as a series of direction changes in time. The "Auto-Pilot" I was talking about before will not really serve this purpose, for I believe it's overkill for it. Also, the Auto-Pilot is intended more for autonomous and non-interactive sequences, like intermissions and introductions.

Regarding the ECS, it's hard to take advantage of it, except for the extra sound card and expanded RAM. I can't think of many games I'd like to play on a retro console that involve a keyboard--especially a stupid, chiclet-sized, unreliable keyboard like the one that comes with the ECS.

Perhaps the Intellivision community would profit from having a series of "Interactive Fiction" games. We could work on a generalized engine for simple text or graphics adventures (a la SCUMM, or SGI) to facilitate making ECS games that require the keyboard. Nothing spectacular like the Z-Machine used by Infocom, but at least simple adventures driven by either point-and-click commands (like newer SGI) or "VERB NOUN" command-line interface (like old SGI).

Something like the classic "Space Quest" or "King's Quest" series should be very much possible on the Intellivision.

-dZ.

a galaga/galaxian close is surely needed in the intv portfolio since we have only couple of games of that sort :-)
a space quest game look to me far away from my capacities: we should think about a joint dev group for this... I guess it's early no for planning such project, we will see :-)

[DZ-Jay]

vprette, on Sun Feb 12, 2012 10:39 AM, said:

DZ-Jay, on Sun Feb 12, 2012 10:21 AM, said:

vprette, on Sun Feb 12, 2012 9:45 AM, said:

My second project I'm thinking about will be called When Empires Collide and it's a galaga clone.
being Galaga complex in terms of animation, I rather start it as a space invader basic shooter, and introduce step by step some better feature, surely a level with one only big enemy ship to be destroied... the dynamic seems to me simple and I guess p-machinery already have what is needed for such a project, am I right?

the only regret here is that I do not see any use of ECS for this kind of game, and I'm motivated to work on ECS games more than standard intv

Valter,

P-Machinery will make it easier to put the game together, but currently it has no special support for sprites. As I mentioned, I will work on a sprite driver for P-Machinery soon, so even that will be covered.

Keep in mind that P-Machinery may not be suitable for all games. Some games, especially ambitious projects that drive the hardware capabilities to their limits, require a level of tweaking and micro-optimization that P-Machinery won't be able to offer with its generalized structure.

And I would say that, although those kind of games are very good and raise the value of the console, they are so hard to program that they either take too long to produce or seldom get finished. If you consider that a game can still be good and fun without stretching the limits of the hardware, then a generalized framework like P-Machinery should suffice for most of them.

In the future, I plan to do both: P-Machinery games mostly, and once in a long while an original game that breaks away from the capabilities of P-Machinery.

As for your Galaga clone, the animation is really not a big deal (I think it's like 2 or 3 frames per monster only). The complexity is in the flight patterns. However, even that can be easily done by defining the patterns as a series of direction changes in time. The "Auto-Pilot" I was talking about before will not really serve this purpose, for I believe it's overkill for it. Also, the Auto-Pilot is intended more for autonomous and non-interactive sequences, like intermissions and introductions.

Regarding the ECS, it's hard to take advantage of it, except for the extra sound card and expanded RAM. I can't think of many games I'd like to play on a retro console that involve a keyboard--especially a stupid, chiclet-sized, unreliable keyboard like the one that comes with the ECS.

Perhaps the Intellivision community would profit from having a series of "Interactive Fiction" games. We could work on a generalized engine for simple text or graphics adventures (a la SCUMM, or SGI) to facilitate making ECS games that require the keyboard. Nothing spectacular like the Z-Machine used by Infocom, but at least simple adventures driven by either point-and-click commands (like newer SGI) or "VERB NOUN" command-line interface (like old SGI).

Something like the classic "Space Quest" or "King's Quest" series should be very much possible on the Intellivision.

-dZ.

a galaga/galaxian close is surely needed in the intv portfolio since we have only couple of games of that sort :-)
a space quest game look to me far away from my capacities: we should think about a joint dev group for this... I guess it's early no for planning such project, we will see :-)

I understand, but the ECS has nothing to offer arcade action games except for additional sound channels. Perhaps a 4-player game too.

However, making a game that takes advantage of these should not cripple the game when playing it without an ECS. In other words, it would be bad to make a game that requires the ECS just to have more sound effects; or that is unplayable with less than 3 players, when it is so hard to find a single partner to play an Intellivision game with you. But it is perfectly adequate to make a game that enhances the experience when using the ECS.

If you truly want to make a game that takes full advantage of the ECS, and therefore requires it, then you need to consider games that require a keyboard, or somehow use the BASIC interpreter (though this may require some reverse-engineering of the ECS EXEC ROM).

-dZ.

Edited by DZ-Jay, Sun Feb 12, 2012 10:52 AM.

[vprette]

my game When Empires Collide will be based on your second release of P-machinery :-)
your nightmare will not finish with Colossa Cave :-)

[Carl Mueller Jr]

DZ-Jay, on Thu Feb 9, 2012 1:18 PM, said:

More variety of input decoders, such as support for two controllers and even including an ECS keyboard decoder.

• A simpler abstraction of printable text functionality that will also support custom GRAM font sets without much effort.
  
• Built-in support for music using Arnauld's tracker (I'll ask him first to make sure it's OK).
  
• A basic Sprite Driver and programming model that is flexible and easy to use.

I also was thinking of writing simple game to accompany a tutorial on how to use P-Machinery in practical situations. Perhaps a version of "Tag-Along-Todd" built entirely in P-Machinery.

Regarding the Sprite Driver, what I want to do is offer a flexible programming model that abstracts all the hard stuff of handling sprites, such as limited access during VBLANK, collision detection, variable velocity, and animations. Something like simple data structures that keeps the state of the objects and are accessible at all times, and then blasted into the STIC registers and cycle GRAM as needed.

Does anybody have any additional suggestions or comments?

-dZ.

An ambitious project… :-)

Have you given thought to how the "limited access during VBLANK" and the "GRAM cycling" will work? There's very limited time available, and depending on the size of your sprites you may have to update two cards for each. That's of course, 16 cards, plus the possibility of sequencing extra cards for background animations. If you plan on updating the STIC registers for each MOB as well… Are you going to update them directly from your "state" records or filling a buffer first and then updating from that? If your state format differs from the register format, you're going to be spending time (as does the EXEC) shifting information into place. To add to that, if you get an interrupt while you're updating the state records you may have flashes of MOBs in configurations you didn't intend (another EXEC problem), which is why rendering to a buffer is a cleaner solution, although it takes a fair bit of memory.

If you're really going to collect collision data too, that adds a lot of overhead, plus the additional memory to save that information. Later, you'll have to dispatch based on interactions and figure out which MOBs need to be handled, and which objects might be interested in collisions with other objects or not. You also have to keep in mind that the data you get is old, since it's based on the active display. By the time you dispatch and handle the collision, the objects may no longer be touching… And you may have already recycled an object into something else completely different! It's a real pain… Which is why I used software based collision detection for DK (plus, you don't want pixel perfect collision detection anyway… Far too sensitive). The problem is worse if you're using multiplexing as the object is more likely to pass through another, since it's not rendered every frame.

Also, if you multiplex you have to keep in mind that you're sharing with other MOBs, and then it's not so easy to match up which object collided with which object.

It's A LOT to juggle… Which is what the EXEC tries to do, and why it appears so "sluggish", since they ended up having to divide the tasks, there being nowhere near enough time to be able to process all eight objects each frame.

Just some things to think about.

Carl
　

[DZ-Jay]

Carl Mueller Jr, on Sat Apr 21, 2012 7:33 PM, said:

DZ-Jay, on Thu Feb 9, 2012 1:18 PM, said:

More variety of input decoders, such as support for two controllers and even including an ECS keyboard decoder.

• A simpler abstraction of printable text functionality that will also support custom GRAM font sets without much effort.
  
• Built-in support for music using Arnauld's tracker (I'll ask him first to make sure it's OK).
  
• A basic Sprite Driver and programming model that is flexible and easy to use.

I also was thinking of writing simple game to accompany a tutorial on how to use P-Machinery in practical situations. Perhaps a version of "Tag-Along-Todd" built entirely in P-Machinery.

Regarding the Sprite Driver, what I want to do is offer a flexible programming model that abstracts all the hard stuff of handling sprites, such as limited access during VBLANK, collision detection, variable velocity, and animations. Something like simple data structures that keeps the state of the objects and are accessible at all times, and then blasted into the STIC registers and cycle GRAM as needed.

Does anybody have any additional suggestions or comments?

-dZ.

An ambitious project… :-)

Have you given thought to how the "limited access during VBLANK" and the "GRAM cycling" will work? There's very limited time available, and depending on the size of your sprites you may have to update two cards for each. That's of course, 16 cards, plus the possibility of sequencing extra cards for background animations. If you plan on updating the STIC registers for each MOB as well… Are you going to update them directly from your "state" records or filling a buffer first and then updating from that? If your state format differs from the register format, you're going to be spending time (as does the EXEC) shifting information into place. To add to that, if you get an interrupt while you're updating the state records you may have flashes of MOBs in configurations you didn't intend (another EXEC problem), which is why rendering to a buffer is a cleaner solution, although it takes a fair bit of memory.

If you're really going to collect collision data too, that adds a lot of overhead, plus the additional memory to save that information. Later, you'll have to dispatch based on interactions and figure out which MOBs need to be handled, and which objects might be interested in collisions with other objects or not. You also have to keep in mind that the data you get is old, since it's based on the active display. By the time you dispatch and handle the collision, the objects may no longer be touching… And you may have already recycled an object into something else completely different! It's a real pain… Which is why I used software based collision detection for DK (plus, you don't want pixel perfect collision detection anyway… Far too sensitive). The problem is worse if you're using multiplexing as the object is more likely to pass through another, since it's not rendered every frame.

Also, if you multiplex you have to keep in mind that you're sharing with other MOBs, and then it's not so easy to match up which object collided with which object.

It's A LOT to juggle… Which is what the EXEC tries to do, and why it appears so "sluggish", since they ended up having to divide the tasks, there being nowhere near enough time to be able to process all eight objects each frame.

Just some things to think about.

Carl
　

Carl,

I am not trying to replicate what the EXEC does, there's no point in that. I am making a simple game framework that will ease the development of many home-brewed games. Obviously it won't work for all games, but it will be open to expansion and customization by the programmer.

The framework I am working on is based on the code used for my Pac-Man and Christmas Carol games, and it is effective. It will force certain constrains on the technical design of the games, but the intention is to facilitate and speed game development, not to stretch the capabilities of the machine.

The sprite driver posts a copy of the STIC registers on VBLANK, and only blits GRAM that require updating (based on a "dirty" flag that is set when animation is effected).

The actual game engine runs outside the VBLANK context, so animations, game collisions, and input handling is all handled outside the critical path, and VBLANK just updates the STIC and GRAM state as necessary. It is rather efficient and effective.

Moreover, I've taken all the lessons I've learned from making Christmas Carol and preparing a framework that I intend to use in my next game. I plan on making it general enough for multipurpose use, so that others can build games from it.

Thanks for your feedback.

-dZ.

[Carl Mueller Jr]

I didn't mean to suggest that you are trying to imitate the EXEC, but you did say you are trying to develop something as general as possible, which was definitely the goal of the EXEC's programmers. Of course, any time you program something to be generalized, you're definitely not going to be pushing the machine to its limitations – that requires specialized programming.

Even if you're setting a dirty flag to sequence GRAM for only those MOBs that require it, you should still be mindful of situations in which many MOBs need their bitmaps updated in a single frame, particularly if you're also sequencing cards used by the background.

One additional thing you might consider updating during VBLANK is the PSG. I find that, when the main game loop falls behind, updates to the graphics are rarely noticeable, but a lag in the music definitely is. That's one thing I would like to change with my engine.

Anyway, good luck, and looking forward to your future releases! :-)

Carl

Edited by Carl Mueller Jr, Sat Apr 21, 2012 8:57 PM.

[DZ-Jay]

Carl Mueller Jr, on Sat Apr 21, 2012 8:56 PM, said:

I didn't mean to suggest that you are trying to imitate the EXEC, but you did say you are trying to develop something as general as possible, which was definitely the goal of the EXEC's programmers. Of course, any time you program something to be generalized, you're definitely not going to be pushing the machine to its limitations – that requires specialized programming.

Even if you're setting a dirty flag to sequence GRAM for only those MOBs that require it, you should still be mindful of situations in which many MOBs need their bitmaps updated in a single frame, particularly if you're also sequencing cards used by the background.

One additional thing you might consider updating during VBLANK is the PSG. I find that, when the main game loop falls behind, updates to the graphics are rarely noticeable, but a lag in the music definitely is. That's one thing I would like to change with my engine.

Anyway, good luck, and looking forward to your future releases! :-)

Carl

Carl,

Thanks for the feedback, I really appreciate it.

The strategy I'm taking is that the game program is divided into primary states (e.g. title, game-play, game-over, etc.) and the programmer registers animation objects at design time with the framework, for each state. Each animation object keeps track of its frame-rate and the number of GRAM tiles it uses, and the animation driver sets the "dirty" flag of any objects whose GRAM needs updating.

The animation driver runs as a task outside VBLANK context, along with collision detection and sprite movements, which are also tasks of the main game loop. The tasks will be prioritized to allow the game loop to "drop" tasks if the queue is falling behind.

The animation objects will also be prioritized, so that whatever is of lower priority can be "dropped" for a particular frame if necessary.

You are right in that skipped frames are more noticeable on music than on graphics; this is something of which I was already aware. To solve this in Christmas Carol, I process the PSG in the ISR, within VBLANK context. I may change this in the generalized P-Machinery framework to be a high-priority task, to guarantee that it is updated.

One more thing I would like to make clear is my target audience. Obviously this framework will not be applicable to intricate and highly complex games like Space Patrol and D2K, which touch the limits of the hardware. The goal is to simplify development of most common games, in order to attract new programmers to the platform.

You see, every year I see plenty of talented programmers join the list, ask a few questions, share some ideas of what game they would like to work on, only to be hit by the hard realities of programming a game in Assembly Language from scratch. Some games are started and never finished, and even more never even go beyond the concept stage.

The worst part, to me, is the lack of abstractions. Some of us struggled to get our first "Hello World" sample program going, only to find out that it did not get us any closer to putting a moving avatar on the screen, or helped us understand in any way how to manage the very limited memory and graphics capabilities.

My goal is to provide a somewhat sophisticated, yet simple, high-level-ish framework that will allow some of those ideas to come to fruition. I plan on implementing a fully-featured game with it as an example, along with a tutorial, to allow fledging home-brewers to cut their chops with minimum pain. They will need to learn Assembly Language, and they will need to write the game logic, but they won't have to worry too much about how to manage and handle sprites and stuff like that.

All of a sudden, those clones of Utopia or ports of Ms. Pac-Man become very much possible, even to the newcomer. Not every home-brewed game need be a ground breaking, technical masterpiece.

And lastly, more than an encapsulated "operating system" as is the EXEC, P-Machinery is an open framework with a runtime environment. The programmer only uses those libraries that he wants, and remove from the runtime environment (within reason) whatever features he doesn't want, at assembly time. With full source, commented and documented, he can also modify any part of the system to specialize it for his own particular game requirements.

Sure, it's ambitious, but I think the community will profit from it, so it is a worthy cause. Anybody who wants to collaborate in this project is welcomed to.

-dZ.

Edited by DZ-Jay, Sun Apr 22, 2012 5:45 AM.

[DZ-Jay]

Carl Mueller Jr, on Sat Apr 21, 2012 7:33 PM, said:

If you're really going to collect collision data too, that adds a lot of overhead, plus the additional memory to save that information. Later, you'll have to dispatch based on interactions and figure out which MOBs need to be handled, and which objects might be interested in collisions with other objects or not. You also have to keep in mind that the data you get is old, since it's based on the active display. By the time you dispatch and handle the collision, the objects may no longer be touching… And you may have already recycled an object into something else completely different! It's a real pain… Which is why I used software based collision detection for DK (plus, you don't want pixel perfect collision detection anyway… Far too sensitive). The problem is worse if you're using multiplexing as the object is more likely to pass through another, since it's not rendered every frame.

The approach I'm taking is to use "pipelining," so that each game-loop cycle sets up a series of tasks that update the state for the next frame. On each ISR, the graphics are updated to reflect the latest known game state. If there isn't enough time before the next cycle, lower priority tasks may be dropped, but the internal state is always updated. The idea is that, on a very intense moment (e.g., when all graphics need updating at the same time, and lots of timers and events trigger simultaneously), we skip updating the visual state of the game for the sake of keeping the logical world state updated in as close to "real-time" as possible.

To answer your question, in order to conserve processing time, the STIC memory space is "shadowed" in RAM. Each game object has a record with velocity, animation, and position information. The record format is optimized for programmatic manipulation. The game logic updates the object state in their internal format, and the game-loop transforms these into updates to the STIC copy or GRAM updates. The ISR then block-copies the STIC "shadow" copy right into the STIC registers in one go, and blits GRAM as necessary.

As for collisions, they are computed from the game objects themselves and the world state--never from the STIC registers. The STIC hardware-collision is a very reliable and convenient mechanism, but it constraints its use to "real-time" detection; that is, you need to update your game state as soon as you read them, or else your practical state does not match your logical state--or worse, your logical state may miss the collision altogether!

It also forces the logical state to be one step behind the practical (visual) state, which may result in strange visual behaviour. As you rightly pointed out, depending on this mechanism is a pain.

As I mentioned before, contrary to the EXEC, I aim to pre-compute a lot of this at assembly-time, rather than run-time. In light of not having a linker, I am relying heavily on macros that will perform the necessary transformations of the game objects structures and encode them in ROM. Two advantages that this framework has that the EXEC never could offer is that the run-time code is fluid, and the programmer has full control over it; and that ROM space is cheap, so extensive pre-computation is not only possible, but practical.

A lot of it is already written in rather specialized code for Christmas Carol. I expect that generalization will be challenging and ambitious, but attainable. Plus, an additional motivation is to construct a practical framework that I can use for my next game.

Thanks for your comments, Carl, I appreciate your feedback very much.

-dZ.

[Carl Mueller Jr]

Sounds great, DZ!
This is pretty much exactly how my engine operates as well. It's interesting that you have a system that drops lower priority tasks when too many objects need updating. I wonder how the logic works out for that. You don't compute it during the VBL, do you?
It just seems difficult to know when you've fallen behind and to try and compensate for it.
I agree 100% about the hardware collision detection. However, there are definitely games that benefit from it. I can't imagine Night Stalker or Astrosmash! without pixel-perfect collision detection. For arcade conversions, boundary box software driven collision detection works great, however.
Looking forward to seeing how your engine works out!
Carl

[DZ-Jay]

Carl Mueller Jr, on Tue Apr 24, 2012 12:30 AM, said:

Sounds great, DZ!
This is pretty much exactly how my engine operates as well. It's interesting that you have a system that drops lower priority tasks when too many objects need updating. I wonder how the logic works out for that. You don't compute it during the VBL, do you?
It just seems difficult to know when you've fallen behind and to try and compensate for it.
I agree 100% about the hardware collision detection. However, there are definitely games that benefit from it. I can't imagine Night Stalker or Astrosmash! without pixel-perfect collision detection. For arcade conversions, boundary box software driven collision detection works great, however.
Looking forward to seeing how your engine works out!
Carl

Actually, the prioritizing is a concept I plan to add in the next version. I don't have it in Christmas Carol. Christmas Carol was built using pretty much the stock SDK-1600, so it uses Joe's TASKQ and TIMER libraries.

My idea is to assign priority at design-time, using a bitmap mask or an index value. The programmer could assign the priority to a graphics object when registering it (or mark it with a "high priority" bit, whichever way I go). During assembly, high-priorty objects will be inserted at the top of the list. Using some heuristics (perhaps using the number of objects processed), the animation driver then can determine whether there's not enough time to process low priority objects.

Anyway, that's just at the top of my head. I've not given it too much thought yet. Any ideas you have will be welcomed.

One more thing that you should consider, and which I think is a great advantage of P-Machinery (or any software library solution) over the EXEC, is that the engine does not have to solve all the problems a-priori. Documentation can be included that offers information on how to optimize or prioritize assets, offering guidance to the programmer on strategies to detect and overcome bottleneck problems during his game development. And since the engine is just another library included with the game code, these suggestions can include modifications to the engine itself for specialization. Then there's always AtariAge and INTVProg to ask questions on how to modify it and build upon it.

Moreover, we can exploit the fact that the system is deterministic, and once a bottleneck is likely to occur for a given program, the sprite driver can be specialized to solve this. Say the programmer registers 12 objects, half of which are double-cards. Pre-computation (as well as empirical data) can prove that there isn't enough cycles in VBLANK to update all of them at once. The programmer can then take measures to avoid the chance, or stagger their updates in two cycles.

Keep in mind that for most simple games, where there are a limited and small number of objects, this won't ever be a problem. Christmas Carol, for example, has at most 6 live, animated objects at any one time (plus score-digit cards), and empirical tests suggest that STIC and GRAM updates are never dropped. The chance of all objects updating at the same time is rather small, and if it ever happened, harmless; just a very fleeting frame skip.

Your comments regarding collision detection are interesting. I've often toyed with the idea of re-implementing Night Stalker, but I never considered using hardware collision-detection. I would have thought that a bounding-box software approach would suffice. On second thought, you may be right.

I guess the STIC collision-detection can be simulated in software by XORing two cards, but this may be expensive when performed for each sprite object against each other (after all, the game engine has access to the current logical state of the world, including sprite animations and positions). Considering that Night Stalker is a rather simple game, it may not be too bad, as long as it's done outside VBLANK context.

-dZ.

Edited by DZ-Jay, Tue Apr 24, 2012 3:55 AM.