next »

[fuedhq]

If you have seen my other devlogs, you probably noticed I pull a lot inspiration from that primeval computer.
Yes it was were I found out how to do computer games, mostly with the help of books and magazines.

After finishing The Outhouse game, which mimics the COCO´s semigraphics mode, I thought why not give a try on doing a game for the real deal?

So here we are. First, I don´t own a COCO anymore, so I will have to rely development on emulators. There is a bunch of them out there including online versions but for my case, XROAR will do. You can download it here:
https://www.6809.org.uk/xroar/

Run the thing and this is what you get:


Now, from this point on, one can already do all the needed game coding since these computers were embedded with a BASIC and all needed stuff for editing a code list. This would be pretty cool to undertake in an oldschool fashion

But I will look into it on a more modern way. Allen Huffman´s articles about this subject fit in perfectly:
https://vintageisthenewold.com/coco-cross-development-part-1/

So now I know how to use ATOM editor with a BASIC extension to produce code and send it to the emulator.
Here is both running and a few test programs I did on the ATOM´s tabs:

[fuedhq]

I will be making this game in semi graphics mode 4, so let´s recapitulate what exactly that means.

There are 32x16 positions to draw a block. There are a total of 256 blocks but I will be using only those graphic.
There are 8 colors and from a full colored block, you have variations with black pixels inside.
The colored blocks above represents all there is, like tiles.

In sum, you can achieve a visual resolution of 64x32 pixels but you have to live with the side effects that inside each block, there can only be one color and black.

[fuedhq]

Now some of you are probably still giggling about this thread´s so far info and most likely because of the words "action" and "BASIC" being put together. In ancient times, there were BASIC and ASM as common coding languages. The first being easier and slower in comparison to the second. That kind of held a bit of truth back them though I nowadays get professional people hinting otherwise, yeah, BASIC can be made faster and ASM is not difficult to learn. Anyways, BASIC is what I currently 'know' and I will have to resort to that so the project doesn´t take ages to be complete

One other point, is that I haven´t tried coding for the COCO for quite some decades but a little bit last year just to get this more modern developing system running and giving a go on an adventure game. So I will have to warm up.

A funny thing is that nowadays modern BASICs are super fast but it still carries that stigma on people´s mind.
Even after the 90s were AMOS, STOS, BLITZ BASIC were already spot on.

But let´s get to the game itself. I want to make a fight game.

The very first thing that might pop into mind is the likes of Street Fighter 2 or Final Fight. Yep it might be something on those lines but I´d say those games are a bit too complex for what I intend at first. If we think of a reference timeline on this genre for my game, I´d put it on the top, most recent ones.


Here are Final Fight (1989) and Street Fighter 2 (1991) arcades. One can clearly see a lot of differences/similarities between them in many aspects. I guess to the point of sub genres, like Brawler or Beat ´em up, etc. Let´s just keep their fundaments in mind.

Then, if I think the earliest fight games I ever played, say, point zero for me on the timeline, it would be Yie Ar Kung-Fu (1985), Kung Fu Master (1984), Knucle Joe (1985) and Karate Champ (1984).


There are a lot of other games between these two points in time that I hope to reference, I´d say the most important being Karateka.


Now, this type of game, fundaments or core gameplay, could maybe be reduced and simplified.
Towards that idea, I think it connects well with Pong (1972).

[fuedhq]

As a kind of combat game, pong sports 2 players each controlling its own pad up and down and they have to bounce back a ball.
The ball starts at the middle and takes a random diagonal direction to boot, it bounces on top and lower parts of the screen, the players are also limited by those bounds.
Your score adds if the opponent can´t deflect the ball, say, whoever scores 10 wins.
The ball resets after score. Each player has a 1 axis control, or say, in d-pad world, two buttons, up and down.


So how would that mutate into a crude fight game?
We rotate the middle line to make it the ground, each paddle on each side can move sideways instead, and are restricted by the screen border or the other paddle. Whoever first press attack button, will have the ball blink in front of him and if while that it touches the other player, he will lose a score point. Score starts at 100 and whoever reaches 0 looses.


Within the differences between both, the later has contact in a sense that players are on the same space and their distance to each other is a strong game element, one is constantly considering that, it is active, while the prime is more passive and has its main attention on the distance between player and ball should it be heading your way.. The game also adds an action button.

That, to me, seems to be the very essence of what a fight game is. The very core gameplay.
One can see how extra stuff got this into the 85´s arcade games I mentioned before and so on. Adding rounds, jump, crounch, other attacks, other pad types, more pads onscreen, etc.

In this game, I will start with that very essence. If that is no fun, the game won´t be either, doesn´t matter the add ons.

[fuedhq]

Back to the color computer BASIC, Extended Color Basic, to be precise, these could be major problems I kind of foresee.

-Total memory for the game is about 30kb. Both the code list size and variables used will eat through it, the use of this memory will dictate what I will be able to have in, therefore, the scope and gameplay of the final game.
-Graphics can only be plotted fast enough, I have to check its performance.
-Code structure is troublesome, depending on how it is done, the performance hit is strong.
-Reading controls, be it keys or joysticks, is performance expensive.
-Game logic and AI will also hit it.
-As well as the size of the game, the bigger it is, the slower it gets.

At this point, it becomes necessary to research that performance to see where I can get to, then to design the game with that in mind.

I know of 3 way to draw semigraphic blocks in BASIC:
-using SET / RESET commands.
-using PRINT command.
-uning POKE command.

Let´s test a full block moving from left to right of the screen. I will draw a block, delete it , move it a block further, start over. Here is the code for it:

Code:

10 TIMER=0:TM=TIMER
20 X=0:Y=16
30 CLS(0)

50 SET(X,Y,3):SET(X+1,Y,3):SET(X,Y+1,3):SET(X+1,Y+1,3)
60 RESET(X,Y):RESET(X+1,Y):RESET(X,Y+1):RESET(X+1,Y+1)
70 X=X+1
80 IF X=63 THEN ?TIMER-TM;:END

100 GOTO 50

Here is how it moves:


As one can see, I need 4 SET calls to make a block and 4 RESETs to erase it so this command is actually drawing pixels inside a block. The time it takes to do the screen move is 186.
Let´s see how that fares against PRINT, here is the code:

Code:

10 TIMER=0:TM=TIMER
20 X=224
30 CLS(0)

50 PRINT @X,CHR$(&HAF);
60 PRINT @X,CHR$(&HA0);
70 X=X+1
80 IF X=256 THEN ?TIMER-TM;:END

100 GOTO 50

As we can see, it takes less code and one less variable variable for position as it only uses one.


The speed is so fast that the GIF capture program could not handle recording it.
The time it took to cover the screen is 34.

The third way, POKE, produces speed similar to PRINT, so no reason replicating that.
Conclusion: SET and RESET are too slow. I had that memory from kid, but I just thought it would be neat to test within numbers.

[fuedhq]

Making a similar test, but drawing and erasing 9 blocks this time, performs at 131 with PRINT.
 

Code:

10 TIMER=0:TM=TIMER
20 X=224
30 CLS(0)

50 PRINT @X,CHR$(&HAF)CHR$(&HAF)CHR$(&HAF);
51 PRINT @X+32,CHR$(&HAF)CHR$(&HAF)CHR$(&HAF);
52 PRINT @X+64,CHR$(&HAF)CHR$(&HAF)CHR$(&HAF);
60 PRINT @X,CHR$(&HA0)CHR$(&HA0)CHR$(&HA0);
61 PRINT @X+32,CHR$(&HA0)CHR$(&HA0)CHR$(&HA0);
62 PRINT @X+64,CHR$(&HA0)CHR$(&HA0)CHR$(&HA0);
70 X=X+1
80 IF X=253 THEN ?TIMER-TM;:END

100 GOTO 50

One notices it flicks a lot, so even at this neat speed, a single draw call is actually very time consuming, one can almost see the block plotting order. What if we POKE them?

Code:

50 POKE X,175:POKE X+1,175:POKEX+2,175
51 POKE X+32,175:POKE X+33,175:POKEX+34,175
52 POKE X+64,175:POKE X+65,175:POKEX+66,175
60 POKE X,128:POKE X+1,128:POKEX+2,175
61 POKE X+32,128:POKE X+33,128:POKEX+34,128
62 POKE X+64,128:POKE X+65,128:POKEX+66,128
70 X=X+1
80 IF X=1310 THEN ?TIMER-TM;:END

Performance is at 239, almost twice slower then 131 from PRINT.
Each block has a POKE equivalent, while adjacent blocks with PRINT can be stacked, so I´m making 6 PRINT calls against 18 POKE calls.

Conclusion: PRINT has the edge over both other modes, even with functions being called to determine values (CHR$).

[fuedhq]

That is a lot of blinking, one may think, how the heck is that going to look like a game?
So I made this other test tool, quite a big one at ~8kb in size, with interface and what not, so that also goes for a warm up.

What you get in this test is individual block drawings (no appending in PRINT) where in you can set from 4 to 32 blocks being pasted (pens) and also 2 modes of drawing. The other options are not quite important, so let´s leave them off (0).

On mode 0, all blocks will be drawn and erased just like we were doing so far.
Mode 1 is different, blocks are added sideways with a delay in space so to make a snake type animation.

See, within modern BASIC coding, I´d draw everything, erase the whole screen, draw everything again and so on. Nowadays computers are so fast that they can do that millions of time in a blink, so all is fine.

Here on the COCO, with the performance we saw so far, drawing the whole screen over an over would be impractical, but then again, whatever you already have on screen, stays there until you plot another block over it, and so, that snaking animation becomes important.

Conclusion: The best performance technique is to draw one frame of blocks right over the other, without erasing it first as one would do on a sprite system.

[fuedhq]

About the last test, things are actually moving faster than I thought so.

At this point, I recalled the articles about BASIC optimization on the COCO by Allen Huffman.
Those are superb stuff and feels essential to a project like this, here is the link:
https://subethasoftware.com/2015/01/03/optimizing-color-basic/

As an example, the last test was made very sloppy with mountains of wastes. It takes about 8kb of the possible 30kb.
After reading Allen´s articles and applying just a few of those changes, the test now takes 6kb and runs about 2/3 faster.

Would you like to try that test? Download both ASC files from here:
https://drive.google.com/file/d/1w6NfLEXCaThanPLmMMV9SLSeEUBCAf3H/view?usp=sharing

Now these were just non-purpose brute force tests, enough to get a direction to explore.
Let´s get back to the game design, I certainly now know that my skills with BASIC will be able to cut for a bunch of blocks in motion, here are some character study:


Now, while the biggest sprite would be neat, it would also mean more blocks to push and more frames to store, probably too risk for me to undertake as it will also mean a shorter game in terms of different enemies and I would like to have a bunch.
We don´t want to cut with the highly detailed dragon killer adventurer knight you have on the left corner...
Within the 3 middle sizes, they all could produce superb results.
I will tend more to a size were animation has some extent, so the 3rd and 4th designs are in.
Unfortunately, as I want them to move on the pixel level, not a block level, and want them in color, some level of black border must be added, and that all makes the 4th design a good balance.

We are looking at an average 3x4, 12 blocks per character, on a total ~24 blocks to paste to render both players in a frame.

With the character specs defined, we are back on tests...

The idea is to paste 2 generic unique players that can stand and perform back and forward movement with animation.
It should give insight into faster drawing, faster code structure and some idea of user input.
A frame for standing, 3 unique ones for forward and 3 unique ones for backward walking.
3 states, 7 frames per player.

I recall the PERFCON test reports a visually ok speed when printing 16 blocks but 32 unique blocks seemed to fart even with the optimized version. I feel if full optimized, it would be just ok... our 24 needed blocks seems a bit dangerously too close to this limit.

But there is a thing with this test now, we are only doing 8 prints each embedded with 3 blocks, last test had a print for each block. Doing less print calls seems to speed things up considerably. If this means we are using 8 blocks for this test and can go up to 32, we are in a very neatly safe margin I believe.



It seems to be pretty fine! And the code is very far from being optimized.
Here is how the characters gets drawn:

Code:

1105 PRINT @X-96,CHR$(&HAA)+CHR$(&H9F)+CHR$(&HA5);
1110 PRINT @X-64,CHR$(&HF5)+CHR$(&HBF)+CHR$(&HF2);
1130 PRINT @X-32,CHR$(&HB1)+CHR$(&HBD)+CHR$(&HA5);
1140 PRINT @X,   CHR$(&HB5)+CHR$(&HB4)+CHR$(&HBA);

Also note that the color computer has a speed poke that makes the machine work at about a third faster if not a bit more. I will keep this for later and not use it if I can. but let´s move on.

Last test took about 4.4kb of our 30kb space, let´s try some optimization.


Now this is quite faster, and there is a lot more that can be done
Its size has shrunk to 2.6kb, very neat!

[fuedhq]

Some stuff I have learned so far.

The results are going great, both players walking at the same time is sure one of the heaviest and constant moment in game.

Adding a bunch of essentially organized code structure, as I´m used to modern BASIC, is not a good idea, it creates such an overhead that slows the game by more than half.
It also seems that the fastest you print, the better. That is, all print calls into short loops.
Since printing performance is a critical feat in this action game, I have to test it further, there must be just more I could do. Sequentially coding player states with its animation while adding the logic into it, seems to me the fastest way to do so.

Another fact, as it is, the game sports 2 unique controlled walking players for ~2.5kb, add about 2 moves to them and one could be looking at an average 5kb per 2 players. This would mean a total of 12 different players...without thinking about other code and game stuff, so we are probably looking at max 8-10, maybe? Gotta take a closer look at code size too.

Made a bunch of tests, it seems printing a full line is quite as fast as printing a single block.
I tried doing string print then because it would reduce 8 prints to 4.
First problem is with memory, it is too much, even if I keep only the players.
Second, on the line print idea, processing the string to generate the line string is also a hard overhead to be happening all the time. So hardcoding the print calls like I kind of have been so far seems to be the fastest and less memory hungry way.
Remember we are looking at 7 frames per player so far, 14 frames each made of 4 print calls so 56 print calls.

[fuedhq]

So now I just went through Allen´s articles noting down all optimization stuff that will come handy.
I hope to code the final game already optimized or at least with a lot of it in, that way I don´t have to go through iterations of it later up and might be able to code the game already experiencing close to final speed and size.

But there is just one last thing. There was a book back in the days called "500 Pokes, Peeks and Execs for the TRS-80 Color Computer", you can check it here on this link:
https://colorcomputerarchive.com/repo/Documents/Books/500%20Pokes%20Peeks%20'n%20Execs%20for%20The%20TRS-80%20Color%20Computer.pdf

These pokes,peeks and execs are more like lower levels calls and checks on the system and I sure don´t know much how they work but they produce some funky results. It might help with drawing, joy/key read and other stuff, so best check it out and note down the interesting ones.

Then, while testing the selected ones, I stumbled into this:
POKE 359,128 Produce different graphic characters for different keys.
Requires ECB, not compatible with disk system.

First, ECB means Extended Color Basic, while CB is Color Basic and DECB is Disk Extended Color Basic.
These are what we could understand as OS versions, this poke is not going to work on DECB, but that should be fine since I want the game on tape...buuut one has to keep an eye on it for compatibility reasons.

Also important to notice, is that 30kb of memory is only possible without the disk system, otherwise we might have something about 22kb or 24 kb available.

Let´s run that poke on a system to check what it does:


What? It seems after I poked it, typing with the keyboard will produce those blocks instead of the usual letters.
If I repeat a key, the block pasted is the same, so there is a consistency going on.
Commands continue to work, notice the screen clears at some point, that is because I typed CLS<enter> and at the end, I typed POKE 359,126, which restores the computer back into normal. Very interesting, even the <enter> key will produce a block instead of carrying to next line.

But how could that do any good to the game?
It is known that the MC-10 computer, which is similar to the COCO and DRAGON, can naturally print those characters by a combination of key presses, our computer can´t. We are currently printing characters this way:

PRINT @X-96,CHR$(&HAF)CHR$(&H95)CHR$(&H9A);

So there we have an overhead for calling the CHR$ and parsing its values 3.
If we change the CHR$ for quoted characters, it is faster and takes a lot of less code space:

PRINT @X-96,"XYZ";

But we don´t want letter blocks, we want graphics, and so it seems that, with this poke, If I find the relationship between keys and blocks, I would just be able to do that. Super interesting and worth testing. Here is the table relationship I found out:


So, at that poked mode, the table seems to have shifted, our gain is to be able to use the left characters that can be created by key, to generate the equivalent block on the right side. The non-keyable stuff could be as CHR$, and if not many needed, could be stringed for speed, so all is fine on this front. One extra thing, printing text while on this mode will be a pain, but the good thing is that I won´t be needing it for this game.

Let´s reduce current test code to single player and make it walk a fixed distance on the screen.
Here it is:

Code:

2 REM POKE 65495,0
3 REM POKE 359,128
20 X=356:Y=372:J=32:K=32:SX=0:SY=0:TX=0:TY=0:TIMER=0:TM=TIMER
910 CLS(3):?@480:?:?
1000 IF SX=0 THEN ELSE 1210
1105 ?@X-96,CHR$(&HAA)CHR$(&H9F)CHR$(&HA5);:?@X-64,CHR$(&HF5)CHR$(&HBF)CHR$(&HF2);:?@X-32,CHR$(&HB1)CHR$(&HBD)CHR$(&HA5);:?@X,CHR$(&HB5)CHR$(&HB4)CHR$(&HBA);
1141 SX=1 :TX=0
1210 IF SX=1 THEN ELSE 1500
1220 TX=TX+1
1230 IF TX=1 THEN ?@X-96,CHR$(&HAF)CHR$(&H95)+CHR$(&H9A);:?@X-64,CHR$(&HAF)CHR$(&HB5)CHR$(&HBA);:?@X-32,CHR$(&HAA)CHR$(&HB6)CHR$(&HBA);:?@X,CHR$(&HB1)CHR$(&HB8)CHR$(&HBA);:X=X+1
1270 IF TX=2 THEN ?@X-96,CHR$(&HAA)CHR$(&H9F)+CHR$(&HA5);:?@X-64,CHR$(&HAA)CHR$(&HBF)CHR$(&HA5);:?@X-33,CHR$(&HAF)CHR$(&HAA)CHR$(&HBF)CHR$(&HA5);:?@X-1, CHR$(&HAF)CHR$(&HAA)CHR$(&HBD)CHR$(&HA5);
1320 IF TX=3 THEN ?@X-96,CHR$(&HAF)CHR$(&H95)+CHR$(&H9A);:?@X-64,CHR$(&HAF)CHR$(&HB5)CHR$(&HBA);:?@X-32,CHR$(&HAF)CHR$(&HB5)CHR$(&HBA);:?@X,CHR$(&HAF)CHR$(&HB5)CHR$(&HB8);
1350 IF TX=4 THEN X=X+1:SX=0
2000 IF X=376 THEN POKE 359,126:?@416,TIMER-TM;:END
20000 GOTO 1000

That is how I have been doing stuff so far, let´s see how it fares:


Speed is at 220 and final memory use is at 0.9kb.

Let´s change the code to incorporate the new poke and also turn non-keyables into variables.

Code:

2 REM POKE 65495,0
3 POKE 359,128
20 X=356:Y=372:J=32:K=32:SX=0:SY=0:TX=0:TY=0:TIMER=0:TM=TIMER:A$=CHR$(&H21):B$=CHR$(&H17):C$=CHR$(&H1C)
910 CLS(3):?@480:?:?
1000 IF SX=0 THEN ELSE 1210
1105 ?@X-96,","A$"'";:?@X-64,"wAt";:?@X-32,"3?'";:?@X,"76<";
1141 SX=1 :TX=0
1210 IF SX=1 THEN ELSE 1500
1220 TX=TX+1
1230 IF TX=1 THEN ?@X-96,"1"B$C$;:?@X-64,"17<";:?@X-32,",8<";:?@X,"3:<";:X=X+1
1270 IF TX=2 THEN ?@X-96,",!'";:?@X-64,",A'";:?@X-33,"1,A'";:?@X-1,"1,@'";
1320 IF TX=3 THEN ?@X-96,"1"B$C$;:?@X-64,"17<";:?@X-32,"17<";:?@X,"16<";
1350 IF TX=4 THEN X=X+1:SX=0
2000 IF X=376 THEN POKE 359,126:?@416,TIMER-TM;:END
20000 GOTO 1000

Speed is at 144 and final memory use is at 0.65kb.

Conclusion: Coding this way produces a third less code and a third speed increase, not bad!

[fuedhq]

It might be worth noting that the use of strings do eat through memory for a little increase in speed.
If I remove it I get 147 speed and 610 size. It is something to think about as both will escalate as the game grows.
In this case, I will prefer to use strings, they might cut off at some point for being reusable and I want to keep speed optimum.

Where we currently stand, some risky projections can already take place.
Say, 0.65kb makes that 1 move and I don´t need a different walking animation, so a few bytes more can deal back walking and controls, the standing position is already there. Here I could maybe safely conclude ~0.75kb should do for each player when code is more optimized. We would be at 1.5kb for two players instead of 2.5kb.
That would mean adding a couple simple extra moves for each will get us at 3kb insteaf of 5kb.

This would mean I could now have ~20 players? :D Most likely not, I also want some level of complexity and different meaningful moves which will make a single player be, hopefully, at around ~2.5kb? Or a bit more? That is something I need to find out

[diegzumillo]

This is really great! I am really enjoying your break down of implementing things on the coco. I had one (a locally produced clone of it, at least) and it's in my earliest memories of using a computer and playing games.

I recently developed a fascination for game making for old hardware by trying to make a Mega Drive game, and somehow I find all this technical specifications and limitations exhilarating. I honestly don't know hwy. The other day I watched a 45 minutes video on the limitations of a machine I never used, and how the developers got around it.

Good luck on the game. By the way, is it a moving fighting game like streets of rage or an arena type like street fighter?

[fuedhq]

Thanks! I´m one of those guys too, had a brazillian CP-400 COLOR 2.
For Megadrive, I tried SeconDimension BASIC and could get a prototype rogue like going. Works pretty neat!

As for the game type, it will be more like Karateka without the scrolling. So I guess it will be single player one on one arena game.I´m trying to envision a Karateka blended with Yier Kung Fu running on Vigilante´s genre.

[diegzumillo]

I'm brazilian too!  My clone was called Codimex.

If you ever want to revisit MegaDrive dev, check out SGDK.

[fuedhq]

Now, about that last poke that shifts blocks and allow direct key-in of some of them, while making the game smaller and faster , it was quite a surprise for me. The last speed you see the guy cruising the screen a few posts up is probably 8 times faster than what I hoped and I sure can deal with a much slower pace.

I took the subject to the community, was curious if someone had seen it before or had any experience with it.
William "lostwizard" Astle, on COCO Discord said something like this:
I'm not aware of anything obviously. You could try intercepting the CHROUT routine and add a "ORA #$80" before returning to the original vector. It's not as straight forward as a single POKE, though.
Such an intercept could be turned off and on with a single POKE once installed, though, since replacing the "$80" in the "ORA" with zero would remove the behavour.
One would need 5 bytes of RAM somewhere that wouldn't get clobbered to do it.

Now that is the exact kind of phrases I would fake a phone call and say those if I wanted to impress people around!
Just joking, while I don´t understand any, it is a step forward into learning the lower levels of the machine, and I will need to do so to learn ASM in the near future. So thanks William end everybody else that takes time to give a hand, it is VERY welcome.

So I took the subject to facebook at TRS-80 Color Computer (CoCo) group.
There, COCO Ur-Quan Mastermind Simon Jonassen had this to say:
you BASICALLY hacked a vector for console out ! - that vector difers between CB/ECB/DECB.....
and your *128* actually just NUKES the JMP at $167.....
JMP is $7e (126) - suba is $80 (128)
it IS however interesting that basic would exhibit this behaviour when you nuke the console out ram hook

Now I see a relationship with what William said, it is more clear though I still don´t quite get it.
Considering compatibility with systems, CB/ECB/DECB, Simon came up with ideas to fudge it.
I will be giving them a try now.

Erik Gavriluk and Murilo Queiroz asked about strings and why not use machine language for all that.
Well, I kind of had a bad experience with memory consumption if I string all graphics in this game, I also could not work the string in a way to print any close to the last speed seen.

On the Machine language(ML) or Assembler(ASM) subject, they are correct. Doing that way instead of basic would mean instant printing full screen speed, the use of the upper 32kb memory, possibility to deal everything in strings, so easier player flipping and a whole lot more... but I don´t know how to code that yet.

One path would be to insert some ML routines into the BASIC program to fasten up the required parts.
This would be a neat stuff, Allen Huffman also covers a bit of it on these articles:
 https://subethasoftware.com/2017/02/05/interfacing-assembly-with-basic-via-defusr-part-1/

While I learned more of it, I still wouldn´t even know where to start.
I will keep in touch with them on this subject, but should push the game forward with what I currently have in hand.

Thanks again chaps! And thanks for all those who offered help, I will sure need it.

[fuedhq]

Back to the design, here is what I would dream about, most likely not all possible but just a guide.
A one on one fight game with a warriors/vigilante mood, the story is the usual damsel in distress of the classics.
I hope for 8 static stages, 4 locations 2 versions each.
It would be neat to have 5 attacks per player and maybe I could sport 21 enemies if I do some sprite recycle and some of the enemies be more simple.

There will be jump but players won´t cross sides. if close enough to touch, they will push themselves back. No graphic flipping. There will also be some trouble with the alpha/background. I´m not sure I can do a routine to calculate that in real time fast enough, but I sure could try something for a single color. The enemies can be hardcoded with their respective background colors, only the main player would need to change per level.

I have some stuff thought out, like movements, backgrounds and other details, but for now a little pause to play a few of the reference games to think more of gameplay.

[fuedhq]

Be trying a live game play of the references here:
rtmp://a.rtmp.youtube.com/live2

maybe that was the wrong link, this one here:

[fuedhq]

A bit more news,
Erik Gavriluk gave out a neat explanation of what is going on with that weird poke and complemented a solution to be able to have the same behavior on all system, be it CB,ECB and DECB. Here is what he said:
Here is what is going on with your POKE statement. Every time BASIC outputs a character to the screen, it makes a call to code at &H167. From there, the code jumps back into the ROMs. That location varies depending on which version ROM the CoCo has.

So he made a small program to automate that and said:
If you GOSUB 1000 it will patch the hook so that PRINT statements output semigraphics (sets the high bit as William Astle suggested). If you GOSUB 1100 it sets things back to normal. It uses five bytes of low memory that are not used by BASIC and should work on all CoCos.

I will be adding this and check Simon´s stuff soon, tell you the truth I have been stuck on the last graphic problem I thought I would have, it is more like aesthetics stuff but anyways, let me share the deed.



That is a part of the walking animation. Screen has a block grid so you can see blocks being pasted over the last one.
The thing is, that pink color you see there is supposed to be the background color, or like an alpha channel.
If I have a fully drawn background, I would have to so some calculations before pasting those pure pink blocks and the ones that are pink and black. I´d need to extract the background block and color and then add the black parts of mine over it.

If that is done, I´d have a neat alpha channel but would have to process this blocks in realtime and so would slow down the game. Gotta keep in mind that gameplay here is more important than visuals for me, so if it becomes a burden, it should be scrapped.

Now, the technique I just described is a bit too much for me to handle, specially since I´m not having strings or data for neither the players nor the backgrounds. What I can do though, is to hardcode a color on the charachter´s animation prints.
If I do that, I´d be able to hardcode stripes, so stuff like this is possible:


Very Karateka uh?
Thing is, if hardcoded, then I will have to have the same blank color on every background.
Now here is what I thought, maybe I could do calculations on the print commands for the player so that depending on the stage, it has a color variable adding up to the CHR$ call which, according to tables we saw before, would help make the player dynamic to single pure colored backgrounds, I might even be able to add stripes. That would slow down the player a bit but the enemies, which are attached to stages and so to backgrounds, would still be hardcoded, so moving as fast as possible.

I´m unsure it would be worth doing that for aesthetics but I have to advance through this dilemma so to start designing stages and everything else. I will solve this tonite.

[fuedhq]

Tested, for this game it won´t be worth, so I will have to hardcode it all and will be able to use stripes that way.
Now to design stuff trying to avoid green and yellow whenever possible.
Least that is a direction and the project can advance.

[fuedhq]

A little small note, Erik Gavriluk, one of the masterminds behind COCO MAX sent help in form of code to deal the background color change so I might be able to do, not an alpha, but a color alpha per scene. Great stuff, I´m still working my mind around the code though.

On another side, I´m making the fundamental required graphics for everything in game, so it takes a little while, but it is advancing. More concrete stuff soon.