next »

[fuedhq]

It is a track from a japanese 60-70 funk collection from films, I love it.
"Funk Sounds From Far East 60s-70s Japanese Film Soundtracks Movies,Grooves Music"

[fuedhq]

Just measured everything as is...
Here is what I have:


So my old version, the 2nd prototype, took 8165 bytes from the 27k available and kept a performance from 8-20 averaging at 14.
It sported 2 different players with ~4 attacks each. This number is here just for reference as that version was very streamlined for memory usage and a bit for performance.

So, current version sports 783 bytes for the system, 106 for a dummy background and then what you see on the table for the states stand, walk, duck, jump, pushed, push.

In general,I would love to be able to keep each state size to a max 500 bytes and to perform at 4.
There will be 4 types of characters using this system:
.Player, biggest one in size at ~6kb.
.Full enemy, at ~5kb, is a clonable enemy with plenty of moves, each clone uses a different set.
.Enemy, at 4kb, are unique bosses.
.Short enemy, at 2 or 3kb, are simpler smaller enemies, like the hawk and the dogs.

Back on the table, it is clear we have the stand, walk and jump states going over what I intend.

Standing is hard because it is the state the computer is checking lots of joystick combinations, that is very time consuming . This state is expected to get bigger in size and heavy on performance as I still have to add checks for the attacks. A drastic solution to fasten it up would be to skip drawing the standing player if he is already there.

Walking is currently a monster in size and perf and should get worse when adding the attacks that requires movement. While I don´t believe I will be able to get its size much shorter, I´m certain I can get a 1/3rd speed boost by changing the first IF layers to an ON GOTO thing. So things are fine here too.

Jumping is already quite optimized but still needs the flykick added to it.

Now why all this deep craze about perf and memory?? Shouldn't they be in check by now?
Yeah yeah...but see, stand, walk duck and jump are heavy processing motions that will be happening most of the time during game, so the game speed is defined here. The state that takes longer, say 5.5, will set all other states to its.

While I would always like faster and smaller, what there is so far is fine. At 5.5 we would have the game going at 13, 1 point faster than last prototype. I believe now it is time to do a final pass on these fundamental states and work with the found values on forth.

edit: how to know the game speed from the chart? Choose any combination of 2 states from STD to PUSH, add their perf number and add 2 (BASE) to the result.

[fuedhq]

Ah, one more thing about the performance numbers per states.
If they are all equal, the game speed is constant, if say, out of five, one is 3, the game will fasten up when that state is performed and if it is 9 it will slow down.

I can´t afford to add a system to control and average these cycles so to keep the game speed constant because it will also cost performance...

So, as I define the game speed, I will design the states to perform at just that, but the thing is, that I want to use the fast and slow motion quirks as a way to add drama to certain motions 

[fuedhq]

And some stress test on the "rock,paper,scissors" jump, stand, duck priority when pushing forward.
Seems balanced now.
Corners were the hardest part to code, can you believe it?

[a-k-]

With blue on blue it's like those optical illusions, sometimes I follow the animation and it looks great, at other times I can't help but see walking tripods...

[fuedhq]

"walking tripods" :D :D :D
Got them fixed!


Joke aside, yeah, blue on blue does that thing.
The first stage, comprising 3 screens, is to depict night to early morning, things should use the darkest colors in which case I only have dark blue. It also fits the main guy better as blue jeans since the other 7 colors are a better fit for specific guys, like policeman, shoreman, no shirt man, etc. After first stage the background colors change, so it won´t be a problem. I might also fix that when doing final pass on them.

And here is a defeated warrior...notice its soul going away...no, it is just dirty pixels calculations.

[JobLeonard]

Souls make for some very dirty pixels

[fuedhq]

So while working with the joysticks, I got back into the button checking part again...
That by nature, is a heavy performance eater. Here is how I was doing it:

Code:

IF G<>255 THEN IF G<>127 THEN IF G<>125 THEN IF G<>253 THEN GOTO 64

The G variable is the result of pooling the joy buttons as in G=PEEK(65280). It pools both joy buttons and returns a whole bunch of numbers like 126 or 254 for the right button, 125 or 253 for the left button, another couple numbers for both buttons pressed and another number for none pressed. All this mess means I have to do that long set of IFs to find what I need and that is what hogs it...If I could do a single IF check, it would be much much faster.

So researching around the interwebs I found a post by Jerry Stratton on Stackexchange where he proposed the following deed:

Code:

10 BU = PEEK(65280)
20 PRINT@0,"RIGHT BUTTON ";
30 IF (1 AND NOT BU)=1 THEN PRINT "ON" ELSE PRINT "OFF"
40 PRINT@32,"LEFT BUTTON ";
50 IF (2 AND NOT BU)=2 THEN PRINT "ON" ELSE PRINT "OFF"
60 GOTO 10

...and that just works! It does with a single IF call, IF (1 AND NOT BU)=1, so that is truly wonderful!
I'm not skilled enough to understand that bit operation (1 AND NOT BU) but  Jerry also did an article on the subject, check it out here:
https://www.hoboes.com/Mimsy/hacks/coco/what-are-8-bits/

Bit-wise operations like that can sure speed things up and while he does a superb job explaining it, I´m not quite into the level of fully understanding it to the point of using the technique on the rest of the code, but I will be fine with the joystick button solution.

Now back on the game, I got punching in, you can do a sequence of up to 3 punches before being back on the stand state. Punching reaches a short distance so you have to be very close. I got energy and stamina systems going on too. Each punch takes a bit of stamina away and if it gets to a certain point, the player gets dizzy. If you are dizzy and get punched, the player does an uppercut for 2 hits. I got low kick in, can be done 2 times in sequence. I got a strong punch and a high kick, that you perform while walking and finally, I got the flykick back in. So now the player carries 7 moves.

Some of these moves are still being tweaked and some sure needs redesigning and better frames but I think I'm now getting closer to a neat gameplay. Here is a video I recorded playing it with friends, what do you guys think so far? (skip to 1:20)




 

[JobLeonard]

I was literally thinking "you gotta learn about bitmasking" as I read the opening paragraphs

Takes a while to get the hang of, but then it's pretty great

[fuedhq]

@JobLeonard , yeah I´m looking into it, but am failing to see how I could use it anywhere else on the code.
Now here is how the looks like without the technique to change letters for the semigraphics.
Pretty cool and I love it since all my 80s games were text based

[JobLeonard]

Yeah it isn't easy to use universally (although it's pretty efficient for tile-mapping, that might be relevant for getting faster graphics), but where it fits it tends to make a huge difference

[Temple of Blood]

So this thread is so amazing that it has made me register here. 

You've really done excellent work here, and I appreciate you sharing your insight and lessons learned with the rest of us.

A few questions, if I may:
1.  Is any development continuing on this game?
2.  Have you tried using the speed-up POKE yet?
3.  Have you tried running it in an emulator and speeding up the "throttle" to make it run faster overall?
    (3b.  Also I have a dumb noob question here and wonder why code running in an emulator can't run just as fast as the HW you're running it on, thus eliminating the need for so much optimization.)
4.  Could you share your code from this game with the rest of us?  I would love to take it and work on it for my own characters, possibly substituting in the larger character design that you explored in the beginning.

Again, well done!

[fuedhq]

So this thread is so amazing that it has made me register here. 

Thanks!

1.  Is any development continuing on this game?

Yep, it is just time is short. All engine is more or less done and working.
I´m making the content and since it is disk based, there is a lot.

2.  Have you tried using the speed-up POKE yet?

Sure, but I will try my best to avoid it. Some cocos don´t like to run it constantly.
So far it is not needed and since the engine code part is done, I don´t think I will be needing it.
The game is running on the designed speed, that is, slightly faster than Karateka but slow enough to take action while the moves are happening.

3.  Have you tried running it in an emulator and speeding up the "throttle" to make it run faster overall?
    (3b.  Also I have a dumb noob question here and wonder why code running in an emulator can't run just as fast as the HW you're running it on, thus eliminating the need for so much optimization.)

Yep, but I only use throttle to speed up test loading and when checking statistics like the speed up GIF example up there.
The XROAR emulator can do up to 1000% I think but sound gets busted, so its muted. Also, this game is to run on the original speed by design, it is part of the challenge.

4.  Could you share your code from this game with the rest of us?  I would love to take it and work on it for my own characters, possibly substituting in the larger character design that you explored in the beginning.

Yep, when it is ready. It is BASIC so anyone can check the code. There will be a second version out of this only for that reason, creating characters.

Thanks again for the interest. If you are into COCOs, check the discord and FB groups, lot´s of action going on, specially this month.

[Temple of Blood]

I'd also be interested in your test code, whenever you feel like sharing it all.  I will need to do something similar for my game that I'm working on. 

I'm resuming a game I envisioned and began in my teens, and it's funny/scary how the commands and ASCII codes came back in my head after so many decades!

I'm mostly interested in making a lo-res game because my art skills are so poor and I think going with hi-res will expose how lousy I am in that department.  Not to mention that I need to eventually put all those hours reading Rainbow and goofing around on the CoCo to use for something impressive.

Thanks again for the interest. If you are into COCOs, check the discord and FB groups, lot´s of action going on, specially this month.

Thanks. I'm too old to even know how to use Discord.   I did sign up for the FB group though, although I don't see a lot of graphics/game design discussion which is my primary interest.

[fuedhq]

If you are going to rock that in BASIC then you will really need to go around a few corners.
Semigraphics is quite the beast to tame on the coco for the resolution and color "clash", ye each 4x4 cell can only have one color and black, nothing more. It makes doing art on such canvas quite a challenge, way higher than the graphic modes.

I intended to run a game course in BASIC for the coco this month, sharing some techniques but time is not gonna allow it this month. I have a few more games going in BASIC too, like a shooter and a graphic lander type game in PMODE1, as well as an strategic adventure game.

Yeah, I´m into game making too and the community is usually more focused on hardware and serious stuff, but there are some excellent games on going, mostly seen on the discord channel.

While you are looking at all these stuff, don´t forget that MPAGD is an engine able to produce machine language games for the COCO and its script language is BASIC friendly, it might be a good thing to examine too.

[Temple of Blood]

Thank you very much for your reply and all the info.

Any developments on your game?

I did decide to try MPAGD, which is a very impressive tool.  When I tried to "Build" for the CoCo, it did nothing at all and I'm not sure where to go from here.

Before I took the leap into MPAGD, I tried to make a semigraphics game that utilized vertical scrolling, by playing off of the way the screen scrolls when an ASCII character is written in the last position.  Even after speeding up my test program with a high speed poke and cranking the throttle it was still scrolling too slowly to use as a game.