commando on a colecovision? - debate

[digress]

I think a good version could be made. I'm not volunteering. I know there was a started version here by

bfg.passion . I was just messing around with some f18a VERY ROUGH concepts to see how the bg tiles might translate and they look very good.

 

The original game seems to have been 224 wide by 256 wide so it would fit without scaling but some cropping of the play field owould heppen but it's a scrolling game anyways..

 

The sprites are just from another game I made but are f18a and are just for example of colourfulness

 

 

 

[Kiwi]

There is an MSX version.

 

I don't recommend converting this MSX version to Colecovision since it's way too slow.

 

I would do 128KB Megacart to store the level tiles in each bank as raw data so it would be a lot faster to read from and load it on screen. Only need one or two byte as pointer to the level data. The screen only scroll one direction. This is one way bypassing the SGM requirement.

 

Sprites in general. Might be hard to multicolor sprites. The helicopter the enemies would share the same bank of VRAM since they aren't both on screen. I'm my mind, 3 color enemy sprite would be doable, 2 would be tower and 1 would be the secondary color. Motorcycle would be 2 sprites cyan while the guy on it would be the 3rd sprites(higher priority than the motorcycle. The enemy could use green as a body, with either black(for the outline) or tan for the enemy skin. They would take up 2 on a line. I would write that sprite engine. The enemy shot would be 1 sprites, maybe max of 4 at a time at the 1 highest and 3 lowest priority rotating.

Ran the emulator at 33% to capture this gif.

The fireballs for example has one has priority over everything but 1 of the player's sprite which is switch priority and lowest priority every frame. This way, the player is always(almost?) visible to the player. So that leaves 2 sprites for the enemies. Which they do change sprite priority, forward and reverse I believe.

 

One of my biggest concern is if all of the player sprites, shots, and enemies can be loaded at once. If not, the game have to cut in framerate(2 delay(1); loop) in half to prevent VRAM curruption and overflowing the VDP stack(if it receive more command than it can handle?[i'm pretty paranoia ]). If it can. It should be fine running at 60fps with slowdown(Unless we get stack overflow like Knightmare.).

 

Other concern if the in game area music will fit in the fixed bank so the data can be safely retrieve when NMI occur and prevent the music slowing.down. Maybe SGM will be needed to transfer music data from bank to the 24KB RAM(I do need the Colecovision BIOS stuff open).

 

Level data is another thing is a challenge. I know I had to manually type in the tile nametable data for my Black Tiger project that's on ice. It can be done in ICVGM, then stack the leveldata in the source code. Drawing tiles is going to take some time.

 

Maybe we can add stuff to the game like bosses and such. Or have your player have armor so he can take a few hits from bullets before he dies. 2 player co-op would be good addition. Probably have to drop one sprites from each player to keep the scanline count up.

 

There is an NES version. Capcom home version usually isn't exactly like the arcade.

 

I do have a history of stopping and go game projects. I'm tempted to write a game engine with my idea above. 6 3-color sprite enemies, 4 enemy shots, 2/3 color sprite player with shared/multiplex shots of 2-4 sprites, boss (? sprites). Of course the sprite on a line limit for those who has f18a isn't an issue.

Anyway, this is my thoughts on this game. It's should be doable for the Colecovision either in C or asm.

Edited April 24, 2018 by Kiwi

[digress]

if i do a version i would develop it to work on a standard colevision first but with a megacart needed of course.

 

then i'd upgrade to f18a as an option. f18a speeds up many graphic routines and has an optional 2nd tile layer that can move independent of the first layer. plus flicker or sprite line would not be a problem.

 

the music would have to go in another bank other than fixed.

 

all the bullets would have to flicker but optionally disabled for f18a

 

and sure options like more than 1 hit point would make it more fun. The arcade is so hard i've barely even gotten past level 1.

 

performance would be my biggest issue. I would make the number of enemy soldiers etc scalable so if there is too much slow down then with a simple variable change you could reduce that to 3 or 4 rather than 6 or 8.

Edited April 24, 2018 by digress

[Pixelboy]

Speaking strictly as a homebrew publisher, it's always bothered me that the Atari 2600 and Intellivision got decent versions of Commando but the ColecoVision didn't. So for a while I envisioned publishing the game, which would have probably been programmed by Mystery Man, assuming I could convince him to do it.

 

But after seeing bfg.gamepassion's version, I'm not so sure it's worth doing. The background graphics in bfg's version were somewhat lacking, when compared to the arcade version, and the Atari 7800 version looks better, given it's from the same general technological generation as the ColecoVision (even though they have little in common in terms of hardware architecture).

 

So if one were to program Commando for the CV, I would expect to see most of the effort put into the background graphics, with the vertical scrolling done in 4-pixel increments. I wish I had time to create a mockup that would demonstrate what I mean, but I don't, unfortunately.

[newcoleco]

hi everyone!

 

I'm glad you decided to start a debate about a ColecoVision version of Commando. It's nice to see fans reacting to project ideas.

 

I will try to be brief. I dislike not seeing the enemies when their sprites vanish because there are too many on screen. So, for a long time, I couldn't imagine a good compromise seeing the arcade footage and how many moving things are there at the same time. I envisaged the graphics to simulate a second color for the player's sprite using characters, make all bullets characters (more than one character to still get some flexibility where the bullets can be), a 4 pixels scrolling (screen) and movement (player), and that's about it. This idea doesn't solve the vanishing enemies problem during a flood of enemies (like at the end of a level) but resolve some vanishing problems by avoiding using sprites for bullets.

 

Seeing that even the Commodore 64 version got an upgrade, why not give it a try and make our ColecoVision version?

 

If you want my music and sounds inspired by Rob Hubbard's chiptune style, check this link: https://atariage.com/forums/topic/276060-what-is-this-music-i-am-working-on/

 

Let's at least dream about it, maybe one day it will be a reality!

 

Regards,

 

NewColeco

Edited April 24, 2018 by newcoleco

[imstarryeyed]

My suggestion would be to keep the arcade levels intact, but if possible create more levels or brand new enemies after you finish the first time around as I always found commando fun until you get through the end of the levels and have to restart. The arcade game is very short with only a few levels which can quickly be mastered.

 

I think it would be a lot of fun to implement the ladders in the NES version where you would throw a grenade and in certain spots open a ladder going down into the ground.

 

In those areas were prisoners, power-ups, traps or enemies or small levels..

 

Here is a video of the NES with some ladders and extra things..

 

If you watch until you get to around 27 sec into the video you can see Super Joe find the grenade power up, and one of the many hidden ladders in the game..

 

 

 

 

I say if possible it would be great to see a unique Colecovision version.

 

In any case I would love to help anyone who can take on the project with ideas if they wanted any.

Edited April 24, 2018 by imstarryeyed

[opcode]

Very had to accomplish unless you don't want it to behave like the arcade, and I will explain why:

 

- scroll puts a heavy burden on the CPU, as it uses a lot of cycles moving all tiles on screen, as opposed to the arcade where you just update a single register

- not enough sprite patterns for 2 colors per enemy, so all enemies would be single color and with way less animations frames. Updating the sprites pattern in real time would just make the CPU burden even heavier, probably affecting frame rate

- since the background isn't just a wallpaper and actually reacts to your movement, the game would control badly, as most of the feedback would be gone

 

Difficult proposition at least

 

EDIT: oh, and the fact the game scrolls vertically means that you can only use 256 tiles for each stage, so everything would be a very rough representation of the original. That also affects a possible F18A version. In fact, in my experience the F18A is mostly good to make small improvements to existing CV stuff, but the 16KB of VRAM just constrains the design too much and generally you won't be able to go much beyond what is already possible with the vanilla CV.

[retroillucid]

It would look pretty much like Frontline IMO.... meh....

[youki]

I don' t think the background Graphics are important in commando . what is important is the gameplay ,the speed and the music.

 

Try the excellent ZX spectrum version. This version could serve as base for a very decent colecovision(+sgm) version. It is quite easy to port game from Spectrum to Colecovision+SGM. Work a little bit on the graphism to add more color , combine the software sprites with hardware sprites , add daniel's Music.

 

and i'm sure you will have on of the best commando on 8 bit plateform.

[+grips03]

This one is nice

[digress]

Looks pretty good & sounds pretty good. The mono coloured bg makes it easy to animate the trees & mounds separately rather than sifting the whole screen.

 

It could also make it easy to substitute some soldiers for tiles rather than sprites. I think this would be the best solution to too many sprites.

 

if using f18a also it can scroll using only a register setting and mattew wrote a small piece of code to offload the tile shift to a small routine that runs directly on the f18a gpu.

 

also I guess does it have to scroll? probably but maybe a series of quick switching rooms might be just as good.

 

I understand this is a bit much for the system but I think it can be done descent.

 

 

I don' t think the background Graphics are important in commando . what is important is the gameplay ,the speed and the music.

 

Try the excellent ZX spectrum version. This version could serve as base for a very decent colecovision(+sgm) version. It is quite easy to port game from Spectrum to Colecovision+SGM. Work a little bit on the graphism to add more color , combine the software sprites with hardware sprites , add daniel's Music.

 

and i'm sure you will have on of the best commando on 8 bit plateform.

I don' t think the background Graphics are important in commando . what is important is the gameplay ,the speed and the music.

 

Try the excellent ZX spectrum version. This version could serve as base for a very decent colecovision(+sgm) version. It is quite easy to port game from Spectrum to Colecovision+SGM. Work a little bit on the graphism to add more color , combine the software sprites with hardware sprites , add daniel's Music.

 

and i'm sure you will have on of the best commando on 8 bit plateform.

[opcode]

I don' t think the background Graphics are important in commando . what is important is the gameplay ,the speed and the music.

 

Try the excellent ZX spectrum version. This version could serve as base for a very decent colecovision(+sgm) version. It is quite easy to port game from Spectrum to Colecovision+SGM. Work a little bit on the graphism to add more color , combine the software sprites with hardware sprites , add daniel's Music.

 

and i'm sure you will have on of the best commando on 8 bit plateform.

 

 

Quite easy? I would love to see that, dynamic scrolling color table and all, assuming you can get 10fps or better.

[youki]

 

also I guess does it have to scroll? probably but maybe a series of quick switching rooms might be just as good.

 

I understand this is a bit much for the system but I think it can be done descent.

 

 

 

i have my own version of commando "like" in progress (said 80% from completion now ) , in my version (for the stock colecovision without SGM) it does not scroll. It is still very playable , but it "not" commando.

 

At start i had integrated the first version of (the one Daniel posted few year ago) commando music . But i had the feeling that the music does not match very well if there is no scrolling in the game. And also for copyright reason i can not use it in a game my publisher will publish . If i release the game it will have an original music.

 

I think for "commando" the scrolling is necessary.

[youki]

 

 

Quite easy? I would love to see that, dynamic scrolling color table and all, assuming you can get 10fps or better.

 

You don't need scroll the color table dynamically. Just be imaginative...

 

And what is "quite easy" is to port from Zx spectrum to Colecovision as is. Adding a little more colors and hardware sprites is a little more work.

[digress]

I agree it might be too slow to be playable like the msx version.

 

 

The Zx spectrum version doesn't use sprites. from what I surmise it uses dynamically drawn (and somehow layered) character sprites. Now being all 1 bit graphics that would be easier but I think that unless you had the potential of 500,000 copies being sold like when the machine was current then i don't imagine anyone would want to do it that way again.

 

They seem to use 2x3 character box but then when shifting it's more like 3x4 box of characters. I think that is even doable. But the layering ...ugh. I don't think I would bother with that.

 

Perhaps use sprites when moving the character to a new character postion then replace him with tiles til he moves again.

 

This is cool guys. Good hear some different perspectives on whether this is even possible.

 

 

 

 

Quite easy? I would love to see that, dynamic scrolling color table and all, assuming you can get 10fps or better.

[Kiwi]

I did think of a way of smooth scrolling is to load 8 set of preshifted tiles into VRAM to switch by loading the register. Should take up 12 KB of VRAM. No that's 16 KB Kiwi. 6 sets of preshifted tile would fit. 2 table of name table for double buffer, since the game only scroll one direction. Screen mode 1, 32 color table mode. There's a hardware bug using the unofficial screen mode that uses 1 color and char table so I think the bug doesn't happen in this screen mode. This is probably the quickest way to scroll vertically.

 

I need caffeine since I just woke up.

 

I think I may do some programming and quick programmer art™ since I'm curious about Commando. And seeing if the game can write the tiles on the 2nd screen while the game is running without having to freeze the gameplay.

[opcode]

 

You don't need scroll the color table dynamically. Just be imaginative...

 

And what is "quite easy" is to port from Zx spectrum to Colecovision as is. Adding a little more colors and hardware sprites is a little more work.

 

 

So please show how it is "quite easy". The TS9918 will require 8 times more color updates than the spectrum, that is why almost every single Spectrum port for the MSX uses monochromatic scrolling areas. In fact ZX Spectrums ports run slower on the MSX because the ZX had direct access to video buffer or whatever it was called by Sinclair, while the TMS9918 needs to go through I/O, but I would love to be proved wrong.

 

Sets of pre-shifted tiles won't work, because you must take into account that upon scroll, the upper tile must donate lines to the lower tile and so on to the subsequent tile, so there are hundreds of possible combinations, unless your background is really boring with just a few different tiles. And screen 1 only offers 256 tiles, so that is another limitation, you can't have a full screen linear frame buffer. Unofficial modes aren't guaranteed to work with some updates of the TMSS9918, and presents many sprite side effects from my experience.

[insertclevernamehere]

I thought the MSX version looked hideous until I scrolled further down and saw the ZX Spectrum version. Commando is a perfect game for Opcode's upcoming console. A standard Colecovision version just wouldn't cut it.

[youki]

I thought the MSX version looked hideous until I scrolled further down and saw the ZX Spectrum version. Commando is a perfect game for Opcode's upcoming console. A standard Colecovision version just wouldn't cut it.

 

The Zx Spectrum version looks hideous but plays extremely well.

[rodge2001]

I think something along the lines of the ZX Spectrum version would suffice for it's smoothness but the MSX version does look more detailed and from what I understand can be easily ported.

 

If done from scratch and/or based off the ZX Spectrum version the bland solid colors and less detail would be a fair trade off if it means the gameplay is thorough and the movement and scrolling is as smooth as possible.

 

Perhaps one screen at a time would work as in when you get to the top it advances one screen upward. Or else perhaps using black backgrounds would be less taxing and allow for smoother faster gameplay with the right amount of objects on screen.

 

Games like Spy Hunter and Bump N Jump achieve very smooth and even faster vertical scrolling with very high level of detail so why couldn't Commando?

Edited April 27, 2018 by rodge2001

[Pixelboy]

Games like Spy Hunter and Bump N Jump achieve very smooth and even faster vertical scrolling with very high level of detail so why couldn't Commando?

Both games you mention perform vertical scrolling in 8-pixel increments, so it's purely tile-based scrolling. This is easier to do on the ColecoVision (although still a lot of work given the video I/O limitations). If the scrolling is fast enough (like it is in Bump 'n' Jump and Spy Hunter) then the choppiness of the scrolling is far less noticeable.

 

For Commando, tile-based vertical scrolling wouldn't look very good. Just look at FrontLine...

[LoTonah]

I don't see we're all of the hate for the Spectrum ZX version is coming from-- I've seen quite a few Speccy games and this is pretty decent. I'd rather see Commando for CV look like it than the turd that is Frontline! Sure all of the objects are monochrome but at least you can make out what they are.

[opcode]

I thought the MSX version looked hideous until I scrolled further down and saw the ZX Spectrum version. Commando is a perfect game for Opcode's upcoming console. A standard Colecovision version just wouldn't cut it.

 

 

That is interesting, because Commando was indeed the first game I worked for the new console when we started developing it in 2012.

[insertclevernamehere]

That is interesting, because Commando was indeed the first game I worked for the new console when we started developing it in 2012.

Awesome! I hope this is a launch title. If so, I'll definitely be getting one the same time as the console.

[digress]

Here is the title screen on an actual colecovision.

I'm going to do a scroll test next of the whole first level bg just to see how it looks on real hardware but there is no game here , i'm just just playing.