INPUT magazine

[matchy]

Did you try semigraphics-24?

[erico]

Semi graphics 24 is how I used to write games in basic using print.
It is a bit hard to convert normal images to it, too low resolution, and again, a set of colors that don´t quite shade.

I think it is best to hand draw it (even though it has a weird aspect ratio) and then manually convert to CHR$.
Here an example image I did sometime ago (in photoshop, but with the proper hardware limits, so it works in a real coco..(not quite)).

EDIT: Street Fighter 2 here would be too clumpy, but a Karateka port this way would be quite possible me thinks...

[Marmor]

hi,

i likeyour ava2 picture style !

[matchy]

That is in "MODE 1 Standard text screen 32 x 16 bytes (512)" which is fine as I still use that and there's some great new MC-10 games which demonstrate sprites with blocks.
Check out "GRAPHIC MODES of the DRAGON and COCO"!
http://archive.worldofdragon.org/index.php?title=Dragon_Notebook

Really cool artwork and I like it so much that we should make a game out of it.    :PI think I'll have to get the coco tools out then. 

[erico]

Thanks Marmor, I once in a while dwell into drawing with the limitations of old hardware(whenever I can simulate such on PC or using emulation with a wacom tablet and tracing with the prior said tool).
There is something beautifully magic for me into those horrendous side effects, color and attribute clashes.

Most possibly, because I was alive at the time and thrilled at the very possibility to have a screen with whatever color, let alone when we were able to actually choose colors at all...

Yep Matchy, that would be mode 1, but I´m cheating there as 32x16 quad blocks of 2 colors equals 64x32 actual pixels.
In my image, there are blocks with more then 2 colors, which is not quite possible.

Back in the days, with basic and me as a coder, it was either a static screen with clear background where "print CHR" moved about, or I used the natural screen scroll when printing over the bottom. All my shooters were upside down!

But Like I said,  karateka would quite fit the restrictions of basic in this mode.
It might be a bit slow, but hey! We have the speed poke for that!

If all goes fine around here, I´d hope to code GLB games with those weird graphics. I still don´t know much how to, but I have an idea for a start.
If you are willing to strike a coco 2 genuine game, I could give a hand on those blocks, just keep in mind that to actually be able to fill up a compromise on my end, it will be around after mid year (if all goes fine).

But deep in the heart, I would love to see a coco II contemporary game.

[matchy]

Yeah it occurred to me later that weren't using even block colors. As black is the common natural, using it as the main background is the only option so making a game in backgrounds any color limited the fore-pixels to single black. Such as green grass or white snow would have black pixel in sprites/objects (group of chr$).

I'm starting to get ideas about an adventure game for the coco 2 extended disk basic and also 3. Perhaps there an adventure construction kit (or even another genre) to try out.
For now, I've imagined implementing the ease of both text/click n point due to the simple interaction and animation. As appose for just a coco 2 game, karateka/fist2/ninja sounds awesome and perhaps I can try some sprite tests but so far I don't feel so positive about animated action games for the coco2.

Recently, I wrote a message vertical scroller, where a colored word would appear and then, in about 20 sec of calculating, scroll up another. I think each letter is like 3x3 char and with the alphabet store in DATA. I wanted to connect this to the comm port as a twitter feed. 

[erico]

Yep, an adventure sounds like an easier endevour and it would be where I would start.
But unlike my text mock a few posts before, I´d drop the text entirely for icons+point and click, maybe text only for dialogs.
Which I believe is what you pretty much just said.

I would still be uneasy on a Dungeon Master x Single image dilemma. The single screen is sure easier but a bit disorienting spatial wise.

A Karateka in text mode would work just fine, it would move on a 32x16 basis but frames could handle the subpixel at 64x32, the paralax of course would be fake and positioning things in a tricky fashion (ye read here design with black backgrounds, or black borders)... would just work out, like the example below 

edit: don´t bother the aspect ratio, pixels would be taller on a real coco, but they are all legal as it is. Would be quite a heck of work to animate that with plenty of frames, but a pleasure job to do none the less.

[matchy]

Alright! Cool.  That's almost perfect although the only issue is moving one or two pixels left or right. In this case, it would be okay except for the inner hand. It's best to separate with black pixels around the feet like with the rest of the character.

Rather than manually working it out, I'll have to create a plotter to produce DATA code. This way, colors will also be able to be set dynamically.

For the background, it would either be loaded from disk or code data.

Code (glbasic) Select Expand


NEW

5 ' HALF OFF A PACMAN MAZE - COCO 2
10 CLS 0
100 FOR Y=0 TO 7
110 FOR X=0 TO 26
120 READ DD
130 EE=2
'130 EE=(RND(4)+2)
140 IF DD>0 THEN CC=128+(16*EE)+DD
150 IF DD=0 THEN CC=128
160 IF DD=-1 THEN CC=128+(16*7)+8
170 IF DD=-2 THEN CC=128+(16*1)+8
180 PRINT @(Y*32)+X,CHR$(CC);
190 NEXT
200 NEXT
300 GOTO 300

1000 DATA 14,12,12,12,12,12,12,12,12,12,12,12,12,14,12,12,12,12,12,12,12,12,12,12,12,12,10
1010 DATA 10,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,10,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,10
1020 DATA 10,-1,14,12,12,10,-1,14,12,12,12,10,-1,10,-1,14,12,12,12,10,-1,14,12,12,10,-1,10
1030 DATA 10,-2,10,00,00,10,-1,10,00,00,00,10,-1,10,-1,10,00,00,00,10,-1,10,00,00,10,-2,10
1040 DATA 10,-1,12,12,12,08,-1,12,12,12,12,08,-1,08,-1,12,12,12,12,08,-1,12,12,12,08,-1,10
1050 DATA 10,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,10
1060 DATA 10,-1,12,12,12,08,-1,14,10,-1,12,12,12,14,12,12,08,-1,14,10,-1,12,12,12,08,-1,10
1070 DATA 10,-1,-1,-1,-1,-1,-1,10,10,-1,-1,-1,-1,10,-1,-1,-1,-1,10,10,-1,-1,-1,-1,-1,-1,10

RUN


[erico]

The moving one pixel left or right would not be problem, I think in no moment the player would actually move as in a sprite concept (like x=x+1 pixel with the same frame). It would change frame as it moves and so the color clash in the inner hand would not be a problem.  [ops, it would be, considering the screen is scrolling sub pixel and the opponent is standing still.
Anyways, it can be designed to fix or the smallest scroll would have to be a full block.]

Same as for the paralax, since only the top part of the wall needs to move, similar to the apple II original version, and even there, it would be easy to code a CHR change to make it move in a subpixel fashion. Same thing for the background on the left. So deep in code, the game is a single screen one. Like just about everything is static but the the top part of the wall and the little bkg on the very beguining of game.

I recall print would only change the target location, it retains the current background over the rest of the image. So a data plotter would be most important as a way to display the hundreds of frames a single character would have?. Since all data is in code, I think it is quite doable.

I would not know how to change the art from the odd to even position, is that what the plotter would do?
I would probably try to get the movement into a full block, but if it is possible to sub move it, then would really rock.

Sorry if I don´t make much sense, went writing as I though about it.

I ran your code on mess, it draws half a maze, heck now I wonder if it would be fast enough to update the game sprites as needed, I even tried the speed poke. hmmm, was there a faster way to plot this graphics? I can´t quite recall. But I remember my print games were fast enough...hmmm

edit: maybe peek and poke the chr$ around?

[matchy]

Again, I will re-visit how the MC-10 games run so fast with sprites because I have tried many speed tricks but can not get anything close to fast enough.  The peeked chars as a sprite will just need two frames with one pixel offset. The requirement can all be handled with a future painter tool/coco data code output. Backgrounds aren't an issue and moving from room to room with be screen switch because I can't imagine side scrolling.

[erico]

Yep, it seems now trouble would be speed of plotting.
Heck was it soo slow?? My games done in print did flicker a bit, but I recall having a half sprite of text moving up in one game and it was more or less ok.

The scroll would be just moving the top part of the wall left or right, and I mean just 6 cross characters as in the example.
There were other pixels to fix on the sprites if they are to move sub pixels.

If I keep looking at that I will end up coding it in GLB just for the sake.

[mentalthink]

I don't read this thread but the last Images I think are done in Glbasic, that's it's cool, make a game with this appareance can be cool!!!

I think King-Fu Master sold a lot of copies in Ipad, well the guy ripped the graphics from MAME Emulator 

[erico]

Yep all possible to run on GLB, I´m found of CHR sets.

[mentalthink]

You have to use SYMBOL AFTER, I'm not sure if only CPC can handle the Chars$ and modify putting you GFX into them.

Will be nice see some game like this but whit very smooth movement, like put 3D into this kind of pixles.. (Blender can do this very easy, have a modifier for voxelize any mesh).

[erico]

It is exactly what I was wondering, to rotoscoope or 3d render to this resolution, would be a fine experiment.
This CHR$ set is from a tandy color computer, but I´m also really found of the DOS set on the BBS style. 16 colors ANSI/ASCII.
Lots of art example here:
http://sixteencolors.net/