How fast are you people at programming?

[psycopathicteen]

To toss out an idea I'm sure has been raised before, if what you're looking for is huge detailed bosses to fight, have you considered devoting a BG layer to them?

That reminds me of something. I need to start using BG layers more often. I do a lot with sprites, but the background is usually just sitting there. I did program a wall to disappear when the "plasma grinch" gets distroyed, so that is a start.

[Drew Sebastino]

I need to start using BG layers more often. I do a lot with sprites, but the background is usually just sitting there.

I think I remember you actually having BG 2 unused. You could have a whole boss be that.

"plasma grinch"

Is it officially the name now?

Edit: Psychopathicteen, I tried your demo and there didn't appear to be anything wrong except one thing: I kicked the "plasma grinch" to about the beginning of the level where you first see the robot guys on the hill thing, and I think I beat him and a vertical column of the level was missing on the hill, but it went away once it was off-screen. I cannot show you a picture, because it's gone and I can't seem to kill him over there again... Might I ask that you implement a pause feature soon?

[psycopathicteen]

I need to fix it so it only updates the vram tile map if it's in the right place in the level. I still wonder if it would be a good idea or not to store the entire level in vram or not. On one hand, manipulating the level will be easier, on the other hand, backgrounds would be less detailed.

[Drew Sebastino]

backgrounds would be less detailed.

That's the problem. I wouldn't store the entire level in vram. I don't want the background to look to repetitive. (Basically with me, with any situation where you would say "it looks better this way, but it's easier this way" 9 ties out of ten, I'd choose the harder option.)

[MottZilla]

How fast and how great of a programmer you are doesn't matter. What matters is the end product. There are games out there that could have been programmed better by other people or with more time. But it works and got done so it shipped and sold. Ofcourse if you are a better programmer then it's more likely your end product will be good.

Also when judging time or how quick you can program something, there is no even metric for measuring that. One person could spend 95% of their day working on something and the other only may have 10% of their day to work on something. Also what is the measure on the work itself? Making some things requires less time than others.

So I wouldn't worry about trying to figure out how fast of a programmer you are. Just focus on good quality work, something readable and maintainable is always good.

[psycopathicteen]

Do programmers who work for companies have to continuously type code without getting the chance to think?

[Sik]

They spend more time reading code than typing. This isn't any different than from hobbyists (if anything, professionals have to read more due to having to spend time understanding huge legacy codebases touched by many people over time)

[rainwarrior]

A lot of programming work at a large company involves talking to other people about code too, not just reading and writing it.

[mcmillen]

So far the net result of all this is a scrolling background and a player sprite that flies around and can shoot guns (I'm working on a shmup.) No enemies yet, though, so it's not really a *game* as of yet

Are you interacting with the sprites directly, or do you already have an object and a metasprite handling code done? If so, dang!

I started off by keeping a sprite table in RAM that's exactly the same format as the real OAM sprite table, and DMA'ing it each frame. That quickly became unwieldy (because of the table filled with "size" and "high x" bits), so I ended up using one byte/sprite to store those and then have a separate routine that packs them into the right format at the end of each frame. I think that's what you mean by "metasprite", but I'm not sure if you also mean more than that

In terms of object-handling code, it's not fully generic yet, but basically in addition to the player, I have an array of shots, each of which has a sprite number, current (X, Y) position, and an (X, Y) velocity associated with them, and they automatically move according to the velocities each frame and are reaped if they move offscreen.

A general tip that I would have (for all programming, even assembly programming) is to do everything in the simplest possible way at first, and only optimize it once you really understand it well. Make liberal use of .define directives both to give your RAM locations helpful names, and even for documentation of registers (in addition to my main source file, I have a "registers.asm" that has ".define INIDISP $2100" (etc), and I only use the symbolic names in my own code.

Clearly document what you're using your RAM for. Up at the top my my main .asm file, I have a comment like this:

Code: Select all

; Memory layout:
; 0000-000F: scratch space for functions.
; 0010-0011: controller state of joypad #1.
; 0012-0013: controller state of joypad #2.
; 0014-0016: 24-bit counter of vblanks.
; 0017-0019: RGB color values to use for background color, from [0-31].
; 001A-001B: 16-bit pointer to next random byte.
; [gap]
; 0020-0021: (x, y) coordinates of player.
; 0022: shot cooldown timer.
; 0023: next-shot state.
; [gap]
; 0030-008F: {sprite, x, y, x-velocity, y-velocity, unused} per shot.
;            If sprite is 0, the shot is disabled.
; [...]

That way I can open snes9x-dbg, click "Show Hex" as my program is running, and inspect everything manually as the game is running, and quickly see correspondences between "wrong behavior" and "wrong values in the important memory locations"

I believe in putting gaps in memory in order to make things line up nicely in the debugger... it's way easier to notice something is wrong when the first shot is $0030 compared to if it were $0024, just because it's at the left edge of the "Show Hex" screen right next to the bright red 7E0030.

[mcmillen]

I see from searching the forum that yes, by "metasprites", you probably mean something more complex than what I currently have.

I more-or-less try to do the simplest thing that's needed to get the job done. I might end up moving to an approach like that eventually, but I'm aiming for "working but simple" before worrying as much about "most general" or "most efficient code-size or CPU cycles wise".

Other people have have different preferences, which are perfectly valid too; this is what works best for me personally

[tepples]

I started off by keeping a sprite table in RAM that's exactly the same format as the real OAM sprite table, and DMA'ing it each frame. That quickly became unwieldy (because of the table filled with "size" and "high x" bits), so I ended up using one byte/sprite to store those and then have a separate routine that packs them into the right format at the end of each frame.

I refer to that as "soft OBC1".

I think that's what you mean by "metasprite", but I'm not sure if you also mean more than that

Metasprite here usually refers to a group of sprites that move as a unit, such as the eight sprites that make up Mario in Super Mario Bros.

A general tip that I would have (for all programming, even assembly programming) is to do everything in the simplest possible way at first, and only optimize it once you really understand it well. Make liberal use of .define directives both to give your RAM locations helpful names, and even for documentation of registers (in addition to my main source file, I have a "registers.asm" that has ".define INIDISP $2100" (etc), and I only use the symbolic names in my own code.

Clearly document what you're using your RAM for. Up at the top my my main .asm file, I have a comment like this:

Code: Select all

; Memory layout:
; 0000-000F: scratch space for functions.
; 0010-0011: controller state of joypad #1.
; 0012-0013: controller state of joypad #2.
; 0014-0016: 24-bit counter of vblanks.
; 0017-0019: RGB color values to use for background color, from [0-31].
; 001A-001B: 16-bit pointer to next random byte.
; [gap]
; 0020-0021: (x, y) coordinates of player.
; 0022: shot cooldown timer.
; 0023: next-shot state.
; [gap]
; 0030-008F: {sprite, x, y, x-velocity, y-velocity, unused} per shot.
;            If sprite is 0, the shot is disabled.
; [...]

So what do you do once the addresses of those variables change due to adding or removing variables? For this, I use the map file that my linker produces.

I believe in putting gaps in memory in order to make things line up nicely in the debugger

ca65 keyword: .align

[mcmillen]

So what do you do once the addresses of those variables change due to adding or removing variables? For this, I use the map file that my linker produces.

I keep the actual locations as symbolic names in the code, like:

Code: Select all

.define joy1 $10

If I change the location, I need to update the comment and the .define, but that's easy enough. Main thing is to not use raw memory addresses in the code itself.

I'm curious about "your linker"; is this a thing you wrote yourself, or ca65/wla? (If the latter, what flags do you pass for it to output a map file?)

[nicklausw]

On the original subject of how fast people can program: for me it depends.

C - there's always a pesky bug that hinders anything and everything I try to do. In the end it always takes forever to do anything.

Z80 - I can work fairly fast with it. Usually my problem is carelessness and stupid little mistakes I failed to notice.

6502 - I'm just beginning to learn how to program this thing, so that answers itself.

Unlike many of you, due to my age I have no right to claim experience, as if I'd been doing this for ten years then that would mean I was programming at the age of 4.

[tepples]

I keep the actual locations as symbolic names in the code, like:

Code: Select all

.define joy1 $10

In ca65, I use the .res command to allocate memory from the next available location in the zero page or BSS segment.

I'm curious about "your linker"; is this a thing you wrote yourself, or ca65/wla? (If the latter, what flags do you pass for it to output a map file?)

From ld65 Users Guide:

-m name, --mapfile name

This option (which needs an argument that will used as a filename for the generated map file) will cause the linker to generate a map file. The map file does contain a detailed overview over the modules used, the sizes for the different segments, and a table containing exported symbols.

[mcmillen]

Thanks! I'd missed it because I was looking at the ca65 Users Guide instead, which mentions a map file only in one place and doesn't say anything about where to get them from. I'll look into it.