Any progress you can show?

[newcoleco]

Hello,

 

Because I'm hosting the Coleco convention this year, I want to emphase a little bit more on the ColecoVision homebrew scene, software and hardware.

 

If you can't make it to the convention but still want to talk about your projects, please reply to this message and share any information, that may include or not pictures and video-links. Please specify if the game project state (not started yet, unfinished, beta, done, or even available in cartridges).

 

I will not surf around the forum and the internet to find the information, please provide links or directly pictures and information, by replying to this message.

 

I thank you all for your collaboration and to keep promoting the Coleco homebrew scene in various forums and during various gamers events.

 

Let's show that the Coleco scene is alive!

 

Have a nice day!

 

(Coleco Adam Convention : ADAMCON 22, summer 2010, June 18-20)

[youki]

Hi Daniel,

 

i have 4 projects on the way for colecovision.

 

One is a Smurf Game . (70-80% done) I hope to be able to complete it around september-october this year. It is an original game nothing in commun with the existing Smurf one except it is based on smurf.

 

2 others games that will share the same engine. The engine is 80-90% done.

First game using the engine is 60% done . (This game is an original one so it require me more time to do)

2nd game 10% done. (this game is remake of an game that already exists on Amiga and Atari St , so less work on "conception" required , it should progress lot faster). I prefer keep secret the name for now.

 

and the last project, is Outrun . A set of routines are already dones. and lot of "conception" problem i had are now clarified.

 

Don't ask me for screenshot or video . I keep the exclusivity for Revival Magazine. And anyway , i won't show screenshots or video until the games have almost its definitive graphism.

[kingofcrusher]

A video of the game I'm working on-

 

http://www.youtube.com/watch?v=V3SFKZau8G8

 

It's not a shooter but will be an adventure game in the vein of The Immortal. It will be finished by the end of the year.

[youki]

Impressive! I'm look foward to be able to play that game!

[Arjak]

A video of the game I'm working on-

 

http://www.youtube.com/watch?v=V3SFKZau8G8

 

It's not a shooter but will be an adventure game in the vein of The Immortal. It will be finished by the end of the year.

 

A first-person, RPG with a real-time raycasting engine on Coleco!?

 

...

 

Dibs on Beta Testing!

 

Seriously, though; this looks absolutely amazing and I can't wait to play it!

[newcoleco]

I've shown your video during ADAMCon 22, sunday morning. And all the programmers, including me, want to see more about your project. Good continuation and thanks for sharing!

[kingofcrusher]

Oh cool, thanks! I'll upload a new video once I get some bugs ironed out. I have to finish Pitfall 2 first, but after that I'll have plenty of time. The next will show the overhead view mode and the battle system.

 

Also, thanks for all the music you post on here, I modified one of yours for the opening song because I couldn't figure out how to do drums. I changed all the melodies and bass, but the beat is the same.

[kingofcrusher]

Here's a new video of what I'm working on. Everything is still early so I haven't polished anything up, and the battle engine will obviously incorporate melee weapons of some sort when I'm finished. Also it's going to be sci-fi, not medieval, the medieval graphics are just holdovers from an earlier build.

 

I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked.

 

http://www.youtube.com/watch?v=KxO5yePdH4E

[GroovyBee]

Here's a new video of what I'm working on.

 

Looks very promising.

 

I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked.

 

How about starting a discussion on the programming forum here? There are quite a few Z80 and Coleco programmers on the board.

[Pixelboy]

Here's a new video of what I'm working on. Everything is still early so I haven't polished anything up, and the battle engine will obviously incorporate melee weapons of some sort when I'm finished. Also it's going to be sci-fi, not medieval, the medieval graphics are just holdovers from an earlier build.

 

I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked.

That is quite impressive, Stephen! Very impressive indeed!

[retroillucid]

Wow! Looks damn good!

Keep up the great work!

[retroillucid]

Here's a new video of what I'm working on. Everything is still early so I haven't polished anything up, and the battle engine will obviously incorporate melee weapons of some sort when I'm finished. Also it's going to be sci-fi, not medieval, the medieval graphics are just holdovers from an earlier build.

 

I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked.

 

http://www.youtube.com/watch?v=KxO5yePdH4E

 

The Battle Sequence is simply wonderfull!!

[+retroclouds]

Here's a new video of what I'm working on. Everything is still early so I haven't polished anything up, and the battle engine will obviously incorporate melee weapons of some sort when I'm finished. Also it's going to be sci-fi, not medieval, the medieval graphics are just holdovers from an earlier build.

 

I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked.

 

http://www.youtube.com/watch?v=KxO5yePdH4E

 

Very nice! Also very interesting. I'm not a colecovision programmer, more of a TI-99'er (which has the same VDP).

 

Do you mind sharing how the writes to the VDP are done ? Could imagine there are a few ways for speeding things up, which most likely

you already know. Here is some of the stuff I used to do for the TI when dealing with the VDP.

 

Should in some extent also work for the colecovision I guess:

 

* Use assembly language for speed critical tasks

* Use inline code instead of subroutine calls where possible

* Avoid many small individual writes, instead use big block writes where possible

* Guess the game screen is in graphics1 mode, so you should be able to have multiple pattern and screen image tables in the 16K VDP ram.

 

1. Fill inactive pattern/screen image table while the VDP registers point to the active pattern/screen image table

2. Switch VDP registers to now point to the filled tables, updating the screen display

3. And back to 1

 

Anyway, looking forward seeing more of your project

[youki]

Looks very promising indeed!

[Arjak]

Here's a new video of what I'm working on. Everything is still early so I haven't polished anything up, and the battle engine will obviously incorporate melee weapons of some sort when I'm finished. Also it's going to be sci-fi, not medieval, the medieval graphics are just holdovers from an earlier build.

 

I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked.

 

http://www.youtube.com/watch?v=KxO5yePdH4E

 

That is epic badassness! I love it!

 

Some general comments:

 

-I love the idea of an RPG on Coleco; that is one genre that has always been lacking on the system.

 

-I love the look of the fighting mode; it has just the right blend of arcade action and RPG technicality.

 

-The initial encounter screen really intrigues me; so many different options and possibilities!

 

Some questions:

 

-Why does it switch to a third-person view in the cave?

 

-How does that health system for each part of the body work? Will having certain sections of the body critically injured cause side effects? (Example: Having your arm severely wounded causes your dexterity and other such stats to be temporarily affected, while severe head wounds could cause death, etc.)

[kingofcrusher]

 

Some questions:

 

-Why does it switch to a third-person view in the cave?

 

-How does that health system for each part of the body work? Will having certain sections of the body critically injured cause side effects? (Example: Having your arm severely wounded causes your dexterity and other such stats to be temporarily affected, while severe head wounds could cause death, etc.)

 

Thank you for the kind words. It switches to third-person just so I can test that engine, normally that would be reserved for special rooms and things like that. Since the viewing window is so small I decided some overhead parts would be a good way to break things up and allow for different puzzles. The health for body parts will affect things exactly like you say, severe head wounds will cause death, but other injuries will affect other things (like walking speed, attack strength, etc).

[kingofcrusher]

 

Do you mind sharing how the writes to the VDP are done ? Could imagine there are a few ways for speeding things up, which most likely

you already know. Here is some of the stuff I used to do for the TI when dealing with the VDP.

 

Should in some extent also work for the colecovision I guess:

* Guess the game screen is in graphics1 mode, so you should be able to have multiple pattern and screen image tables in the 16K VDP ram.

 

1. Fill inactive pattern/screen image table while the VDP registers point to the active pattern/screen image table

2. Switch VDP registers to now point to the filled tables, updating the screen display

3. And back to 1

 

Anyway, looking forward seeing more of your project

 

It's entirely in assembly:-) I'm curious about what you mean by switching pattern tables, is that what double buffering is? I hadn't thought of that-- that would remove the annoying wave as the screen updates. I have a section of VRAM dedicated to the viewing window, so basically the way it's working is it clears 64 bytes of RAM for an 8 tile column (it was 11 tiles, but this way I only have to write color to one color table instead of 2 which means I can actually add color back in), then scales one slice of the texture to the lower nibbles of each tile, then on the next angle pass it scales to the upper nibbles and then ORs each nibble with the other. Every two passes it writes the full tile column to VRAM. I'd love to be able to hold the entire screen in RAM then just do one huge update, but the Coleco only has 1k so that's out, I can fit at most 2 tile columns at once in RAM without sacrificing other areas of the game.

[+retroclouds]

Yes, that would be double buffering.

 

As mentioned, I suppose you are using graphics 1 mode.

For displaying a screen in that mode you need 768 bytes [32*24] for the tiles and

2048 bytes [256 * 8] for the patterns that make up the tiles.

This means you need a total of 2816 bytes for displaying a screen (not including the

color table).

 

Knowing that the VDP has 16K of video ram this leaves plenty of space to "store" multiple

screens in the VDP memory. By setting the VDP write-only registers #2 and #4 to the correct

values, it will immediately display the new screen.

 

From the VDP programmers' guide ....

 

VDP register 2
==============

Register 2 tells the VDP where the starting address of the Name Table is located in VRAM. The
range of its contents is from O-F. The contents of the register form the upper four bits of
the 14-bit VDP address, therefore making the location of the Name Table in VRAM equal to
(Register 2) * 400 (Hex).


VDP register 4
==============

Register 4 tells the VDP where the starting address of the Pattern Table is located in VRAM.
The range of its contents is from 0-7. The contents of the register form the upper three bits of
the 14 bit VDP address, therefore making the location of the Pattern Table in VRAM equal to
(Register 4) * 800 (Hex).

 

 

Note, perhaps you should create a new development post for your project here on atariage.

I'm sure quite some folks will be interested in it

[kingofcrusher]

Awesome, thanks for the tip, that should make a big difference. I hadn't even thought about that, but after researching how some other people did raycasters on old systems I saw double buffering come up alot. Right now though I'm using VRAM for decompression of the maps so I'll have to move some stuff around, but that should work great.

 

Starting another thread is not a bad idea, I have a few questions that you guys could help me with since obviously you all know the VDP WAY better than I do.

[GroovyBee]

Starting another thread is not a bad idea, I have a few questions that you guys could help me with since obviously you all know the VDP WAY better than I do.

 

We don't all know the VDP intimately or your system or processor for that matter but as game programmers we all solve problems in a different way. If you explain what your bottleneck is with algorithms, code snippets etc then there is a good chance we can suggest alternate ways of achieving the same goal.

[Kiwi]

I'll pitch in what I have working on so far, it is not much. I'm slow in learning new things, especially with programming. Here I have so far. Looking over newcoleco's programming example helps solve some issues. Also, the programming guide helps too.

 

http://www.youtube.com/watch?v=pGqeCIAt5EU

The old BlueMSX emulater ran these game at a slow speed, Meka ran these programs at the correct speed. I used BlueMSX to capture the games in Windowed Mode with HyperCam 2

 

The text/graphic adventure is the one I will be working on now after 6 month delay. I'm surprised that the RLE compression scheme works so well since both roms are under 3KBs. I haven't include the Kiwi animation screen into the text adventure program yet.

 

The Kiwi animation screen was inspired by Defender of the Oasis(Game Gear) SEGA animation screen, where the Sega logo zoom in to the screen. I figure that they use tiles for the logo all the way zoomed out. Then as it get closer, it change to a 2x sprite. Then becomes 1x sprite. That's the way I did this screen.

[newcoleco]

Nice graphics and animations!

 

 

Check my Youtube video about BlueMSX in ColecoVision mode. And, you can use BlueMSX to record a video, no need for hypercam or camstudio or any other screen capture program. And maybe the FREQ is set at 50Mhz instead of 60Mhz, check the emulation TAB.

 

What I've done for the vast majority of my ColecoVision videos on Youtube is creating an AVI file with BlueMSX and a codec with not much agressive compression, then Open the result in VirtualDUB to crop the borders (64 pixels on the left-right sides, 48 pixels on the top-bottom sides) and resize to a nice resolution for Youtube videos.

Edited August 18, 2010 by newcoleco