Opinion: Order of routines in game?

[DanOliver]

I can see where writing demos would be very different. Kind of like creating a library where you want to be very organized and you wouldn't need the full ROM or RAM. So cost of JSR, etc... wouldn't be a concern for framework code around the demo code. And I assume that would drive what kind of tools are useful.

 

Doing a game (for me at least) is an intense, short time frame, and when it's done, its done. Changing the code later or being understandable to others is not an issue.

 

When I moved from games to writing frameworks, libraries, etc... it was so much more relaxing. Still very interesting, but a very different process. With games you're crafting pixels on a screen and that's all that matters. With frameworks you're crafting code and that's all that matters.

 

These days it sounds like most people writing 2600 games work on the game for short burst of time over a long period. That might require a tool set more like the writing demos and then pulling all that together at the end which might be more like the intense type of development.

 

Interesting.

[Kylearan]

I can see where writing demos would be very different. Kind of like creating a library where you want to be very organized and you wouldn't need the full ROM or RAM. So cost of JSR, etc... wouldn't be a concern for framework code around the demo code.

I think developing demos and games is quite similar, at least when it comes to resource needs. In demos, especially 4K, you definitely cannot waste any ROM, as effect code, tables, music etc. just need a lot of space. So any cost of JSR etc. are definitely a concern.

 

So I'd like to reiterate that K65 is *not* a framework in the sense that it provides any run-time libraries or routines. It's just a compiler for a language that directly corresponds to 6502 assembly.

 

Doing a game (for me at least) is an intense, short time frame, and when it's done, its done. Changing the code later or being understandable to others is not an issue.

Yep, same here for demos.

 

The difference between demos and games I guess might be that you can spend an intense, short time frame on one effect and then take a rest before tackling the next effect, as effects usually are independent from each other (with the exception of global flow and sync to music). I guess a game is a more coherent whole that might be harder to split into independent pieces (levels perhaps?).

 

These days it sounds like most people writing 2600 games work on the game for short burst of time over a long period. That might require a tool set more like the writing demos and then pulling all that together at the end which might be more like the intense type of development.

True. I guess the demographics of 2600 coders has changed a lot since the early days (older people with more complex lives and less spare time), resulting in different development needs. Modern tools can help there.

 

But I'd wager that modern tools would have helped productivity in the olden days as well, only they haven't been invented/built yet.

 

If modern tools and the way you develop software with it is more fun is a different matter and depends on individual tastes. I like both, and switch between them. Writing TIATracker was a very modern process (IDE, GUI designer etc.), so the 4k demo I'm developing at the same time is using dasm again for a change.

[Kylearan]

Is the framework/runtime library for the routines in Ascend in K65?

No runtime library required, as K65 has none. You only need the compiler itself (found here) to compile Ascend.

 

(Caveat: I think there was a slight change in syntax after Ascend was finished, so it might be you need to do a small change to the source to make it compile with the current K65 version. Contact me if you actually want to do this.)

[Thomas Jentzsch]

With just 128 bytes, you often have to share RAM. Making sure, that this sharing is efficient, safe and easy to use is often quite difficult.

 

How does K65 handle reuse of (ZP) RAM?

 

I am using "overlay" macros for this, which define the required RAM space based on the maximum number of RAM defined in the overlay. Also the overlays can contain nested overlays. This works quite well, but I am always looking for improvement.

 

Here is an assembler output example of "The Stacks":

OverlayScoreTemp:SCORE {
}   14 bytes
OverlayScoreTemp:OUTSIDE_KERNEL {
} * 15 bytes
OverlayScoreTemp:OUTSIDE_HANDLER {
} * 15 bytes
OverlayScoreTemp:OUTSIDE_JOYSTICK {
}   7 bytes
OverlayScoreTemp:OUTSIDE_DOORCHECK {
}   6 bytes
OverlayScoreTemp:ROOM_TEMP {
}   12 bytes
OverlayScoreTemp:ROOM_KERNEL {
}   1 bytes
Overlay:OUTSIDE_VARS {
   OverlayOutside:OUTSIDE_ENEMIES {
   } * 15 bytes
   OverlayOutside:MAP_GENERATION {
      OverlayOutsideMap:MAP_RANDOM {
      } * 4 bytes
      OverlayOutsideMap:MAP_CONTEST {
      }   3 bytes
   }   12 bytes
} * 34 bytes
Overlay:ROOM_VARS {
   OverlayRoomEnemies:ROOM_PEDO {
   } * 3 bytes
   OverlayRoomEnemies:ROOM_PUZZLE {
   }   1 bytes
} * 34 bytes
Overlay:TITLE_VARS {
}   25 bytes

Overlay max. size: 34 ( Overlay:ROOM_VARS )
OverlayScoreTemp max. size: 15 ( OverlayScoreTemp:OUTSIDE_HANDLER )

What you see are two overlay areas (Overlay and OverlayScoreTemp).

• The RAM in "OverlayScoreTemp" is used by seven different parts of the code, the maximum size is 15 bytes, used by OUTSIDE_HANDLER (and OUTSIDE_KERNEL).
• "Overlay" is used a bit more complex. It is used by three different area (OUTSIDE_VARS, ROOM_VARS and TITLE_VARS), the maximum required size is 34 bytes. You can see nested overlays (e.g. "OverlayOutside"), which also have nested overlays ("OverlayOutsideMap")

The maximum usage is always marked with a '*', so that you can easily see where optimizing for RAM space makes sense. Edited May 30, 2016 by Thomas Jentzsch

[Kylearan]

How does K65 handle reuse of (ZP) RAM?

RAM definitions are essentially done the same way as in dasm, i.e. without any automation for RAM re-use. You have to plan and define vars by yourself unfortunately.

 

I am using "overlay" macros for this

Those look quite useful!