WIP: Jack B. Quick, side scrolling demo

[Mark2008]

The computer I develop on....is not playing colecovision games correctly...can you believe that. I guess its not fast enough.

 

Well......that makes it hard to know if there is a slow down in the demo, or its just my machine. The last time I transferred this ROM to a faster machine...it was smooth. Whether it still is....don't know, but before the game is released, of course I will have it smooth.

 

these are quite long term projects, perhaps.... I'm not trying to announce any imminent game...but, since I did bring up the topic of a side scroller....here is a ROM that kind of shows what I'm talking about.

 

And you'll see I put on the first screen most of the tiles...I did that on purpose as kind of a demonstration as to how it works.

 

The screen will have more detail at the top, and I will place mountains and shrubs, to also appeal to the eye.

 

I may move it away from the Mario style, to the Jack Be Nimble, Nursery Rhyme world I envision....centered aroudn the medieval game of candlestick jumping.....

 

but....anyway...enjoy

scrolling.zip

[Cybergoth]

Looks smooth in meka.

[Mark2008]

Looks smooth in meka.

 

You know I already had vColeco, and then changed to blueMSX.

Now I just tried Meka, and its even better.

 

On a core 2 duo machine, they all work fine, but...on this laptop which is a mobile sempron 3500, blueMSX and vColeco have some real hiccups trying to play the demo......Meka did better.

 

It's surprising to me. I would have thought any modern or even a few years old processor, could do the emulation of a colecovision easily...but in this style of game, it's necessary to update the screen just as real hardware would do it, with no skips, and it seems on lower end processors, vColeco and blueMSX struggle just enough (for whatever reason, perhaps to how they share processor time with Vista, which is probably the real processor hog).....

 

but meka did make it look better...as did running on a core 2 duo. Interesting.

[Pixelboy]

I just tried the ROM on the real hardware, using my USB cart, and it works like a charm.

 

The demo doesn't answer our question about using 2-pixel scrolling increments though...

[ScottHuggins]

Looks very nice! However, at 13k already for just a demo...I am guessing you are coding all in C, right? mmmm.... gonna hafta change that, I believe, if you wanna make a game out of this. Don't be afraid- Z80 Assembly language is your friend!!!!

 

 

 

I just tried the ROM on the real hardware, using my USB cart, and it works like a charm.

 

The demo doesn't answer our question about using 2-pixel scrolling increments though...

[Mark2008]

Looks very nice! However, at 13k already for just a demo...I am guessing you are coding all in C, right? mmmm.... gonna hafta change that, I believe, if you wanna make a game out of this. Don't be afraid- Z80 Assembly language is your friend!!!!

 

 

 

I just tried the ROM on the real hardware, using my USB cart, and it works like a charm.

 

The demo doesn't answer our question about using 2-pixel scrolling increments though...

 

Thanks for testing that on a real coleco. I plan on having the ability to do that, someday.... I got an eeprom burner, but, still don't have the eeproms in yet. that USB cart is a real neat invention too.

 

well you are correct, it is currently all in C. And....I think you are also right, that some Assembly will be required....uhm, to coin a phrase.

 

But... I will say one shouldn't look at the 13k size. Daniel Bienvenue has some reduced sized libraries that he used for his 4k games, like Diamond Dash. I used those libraries in Pacific Fleet, but when I started this demo, I just used the same base as Frog Feast.... those were based of the libraries de Kogel had for download on his website. The only reason for the switch, is I was learning about the sound, and if I remember correctly, I found something in there having to do with sound i wanted to try, when I was doing Frog Feast.

 

So...anyway, it can use smaller libraries, just as a start, and could also do some other things (RLE perhaps) to get the size down.

 

Adding another map, using the same graphics would take about 200 bytes or so....not a big jump on ROM space...and each new world doesn't take quite as much space as the first, because usually some elements can be borrowed...

 

but PixelBoy and I are also working on an SMB clone, suffice to say, its going to be cramped to fit onto 32k. Since many of the routines I write will be used on that game too, I probably will start on the assembler coding. argh...I'm no guru on assembler, but I guess i'm fixin to get a lot of practice....lol

[Mark2008]

p.s.

 

The TI-83 plus calculator has a version of Super Mario Brothers...written entirely in Assembler.

 

http://www.ticalc.org/archives/files/fileinfo/192/19225.html

 

Like the colecovision, its a Z-80 processor.

 

Can you believe the luck, I now have two full source versions of Super Mario Clones, one in C and another in Assembler.

 

now the TI-83 has a black and white, 96 x 64 screen.....certainly thanks to the minimal graphics data being pushed around, they should have a smallish executable....and indeed, they got Super Mario Bro. into 10k

 

How much, if any can I use from either of these two sources, is debatable...but what is no doubt, is that at least some of it will be helpful.

 

well well....an embarassment of riches...still if any Assembly language programmers want to join this project...the more the merrier, I don't mind at all.

[Mark2008]

The demo doesn't answer our question about using 2-pixel scrolling increments though...

 

I finally got around to 2-pixel scrolling increments... at the moment it has a small graphical glitch because I was using frame 7 to clean up the trailing pixels...

 

but anyway, I tried it both 2-pixel and having that cause double speed....and 2 pixel, and waiting for every other nmi to update.

 

Both looked very smooth. I'd say lets go to 2 pixel....