TANK MISSION for Colecovision & ADAM

[digress]

Well, you never know but let me get through this one first. Been having some technical problems that have been holding it up.

 

Intellivision is a very nice console too which I do support but have not programmed much for yet. Just some tests. I do have a number of the recent homebrews too so it's cool what has been coming out.

 

Treasures of Tarmin was a lot of fun in the 80's

Frog Bog is awsome 2 player game

I like the horse racing

and I think intellivion boxing is the best boxing game of the 3 systems, atari 2600, colecovision & intellivision.

 

 

 

 

This game is looking amazing and will be a must buy for my CV....that said, I do believe you know that if you made an Inty version we'd support the heck out of that.

[digress]

I replaced some sfx , got rid of "HAHA" and put in auchtung & "gott in Himmel" I'll attempt to get better fx but it's got a limited range of quality to be able to play without stopping the gameplay.

 

https://www.youtube.com/watch?v=3SWgu7FI9l8&feature=youtu.be

[Tursi]

If you don't mind the effect, you can try up-shifting the pitch of the samples before you convert them. The tools have an easier time with higher pitched voices.

[+cmart604]

Well, you never know but let me get through this one first. Been having some technical problems that have been holding it up.

 

Intellivision is a very nice console too which I do support but have not programmed much for yet. Just some tests. I do have a number of the recent homebrews too so it's cool what has been coming out.

 

Treasures of Tarmin was a lot of fun in the 80's

Frog Bog is awsome 2 player game

I like the horse racing

and I think intellivion boxing is the best boxing game of the 3 systems, atari 2600, colecovision & intellivision.

 

 

 

 

Well I hope you decide to do this game for the Inty as well. Just think, you'll have Nano and Tarzilla and Groovy and Freewheel and others to help you with any questions that may arise.

[digress]

I'd probably be more likely to make Mr. Turtle for Intellivision. But being it was for coleco first I'd have to make it look really crappy on purpose.

 

But seriously I was programming on intellivision today and it seems not too hard to work with so I might make a game for it eventually. It really helps when you have a strong community that likes homebrews similar to colecovision.

 

Well I hope you decide to do this game for the Inty as well. Just think, you'll have Nano and Tarzilla and Groovy and Freewheel and others to help you with any questions that may arise.

[Centurion]

I replaced some sfx , got rid of "HAHA" and put in auchtung & "gott in Himmel" I'll attempt to get better fx but it's got a limited range of quality to be able to play without stopping the gameplay.

 

Keeps getting better! Nice work.

[digress]

I like your avatar. It reminds me of centurion for dos pc.

 

Hack & slash game next I think

 

 

 

Keeps getting better! Nice work.

[Jinks]

Always could use more 7800 homebrews

 

I second this. Usually about 150 or so people would want to buy a copy.

[digress]

So the last major section is the fighter plane section that was still pretty weak.

 

Now it's much better.

 

Now you get to fly as the stealth fighter.

-reversed the flying direction so it's more like cosmic avenger and most other fliers

-Now with 2 speed slow and jet afterburn

-must destory all 5 v2 rockets before you can land

-can pick up additional fuel & bombs

-missle launching derigible

-squadrons of enemy planes that shoot at you

https://www.youtube.com/watch?v=rCRg5AXplPM&feature=youtu.be

[TPR]

I really love how much you keep adding to this game! It's great!

[imstarryeyed]

Wow I am consistently amazed how this game is coming along. I really am impressed on how much this game has changed over the period of time. I am really looking forward to buying this when it comes out and also get a copy of Mr Turtle too!

[Kiwi]

Wow, this is looking incredible. I really love the smoke effect from the plane.

[digress]

Thanks, I want it to be as good as possible. This section needed improvement. It is much more fun now.

I really love how much you keep adding to this game! It's great!

 

I'm pretty happy with Mr. Turtle too. There are things I would change if working on it again but it's what I did at that time and overall it turned out well. And I'm sure, barring cheating, no one but me has ever beaten the hard level. Apparently the easy level is pretty hard for that matter but managable. I play tested it so many times that I can beat it on any level.

Wow I am consistently amazed how this game is coming along. I really am impressed on how much this game has changed over the period of time. I am really looking forward to buying this when it comes out and also get a copy of Mr Turtle too!

 

Thanks. The smoke really helps to emphasize you are traveling faster and that you are burning fuel much faster too!

 

Plus it helps with the burning plane effect greatly.

Wow, this is looking incredible. I really love the smoke effect from the plane.

 

[Bmack36]

Have you looked into the F18a's harware scrolling? The demos on the TI99 using the F18a for scrolling look amazing.

 

https://www.youtube.com/watch?v=Vcn85aF3aBU (skip ahead to the 1 minute mark)

Smooth scrolling and no flickering could make this look really great (It does look really good right now as is)

[digress]

looks cool. I'm not afraid adopt anything like this except that very few people have an f18a. I don't have one either.

 

Perhaps I could look into it a bit more and see if it's something that could be optionally used if present but will work without.

 

Have you looked into the F18a's harware scrolling? The demos on the TI99 using the F18a for scrolling look amazing.

 

https://www.youtube.com/watch?v=Vcn85aF3aBU (skip ahead to the 1 minute mark)

Smooth scrolling and no flickering could make this look really great (It does look really good right now as is)

[Bmack36]

I think having the ability to enhance for those that do have it while still working for those that don't would be really good. I think the F18a should be getting out to a lot more people with the new motherboard project. I think having a game that showed off its abilities would also push a lot of people to get the upgrade.

[Tursi]

I love the little Canadian flag at the end.

 

The F18A effects are absolutely detectable and can be switched in and out. I haven't done a lot with the scrolling but Matthew has (TI) example code showing how it works.

[digress]

I'm looking into this now. Not sure if anything will come of it but I'll read the info I can find.

 

The main thing is I want it to work on a stock colecovision first and this might be optional.

[+Tarzilla]

 

So the last major section is the fighter plane section that was still pretty weak.

 

Now it's much better.

 

Now you get to fly as the stealth fighter.

-reversed the flying direction so it's more like cosmic avenger and most other fliers

-Now with 2 speed slow and jet afterburn

-must destory all 5 v2 rockets before you can land

-can pick up additional fuel & bombs

-missle launching derigible

-squadrons of enemy planes that shoot at you

https://www.youtube.com/watch?v=rCRg5AXplPM&feature=youtu.be

 

I love the stealth plane, reminds me of the flying wing from Raiders of the Lost Ark

[digress]

You just gave me an idea.

 

I love the stealth plane, reminds me of the flying wing from Raiders of the Lost Ark

[+Tarzilla]

You just gave me an idea.

 

I hate it when I do that....

[matthew180]

... except that very few people have an f18a...

Interesting perception. I'm curious what you are basing that information on? To date there are about 400 F18A boards out in the wild, and probably close to half were sold with tall-pins (which typically means it went into a CV).

 

Perhaps I could look into it a bit more and see if it's something that could be optionally used if present but will work without.

Since you already have tile-based scrolling, then using the F18A's scroll registers to get smooth pixel scrolling could be as simple as adding seven VDP calls in your game loop between the tile updates. However, with pixel scrolling you have to have tiles ready to be scrolled in, which means either masking a row or column (depending on vertical or horizontal scrolling), or using multiple name tables. Using multiple name tables allows you to have the whole screen for scrolling, and either way you need an extra name table in VRAM.

[digress]

I don't mean any offence by that and that sounds great . I'm referring to colecovision install base only and not overall. If it's not like %80 of current colecovision users so I would not want to make a game that didn't support both the stock system and the enhanced system.

 

But I am certainly interested in adding support for it. It would also fix the 4 sprites per line when I have some bullets or sprites disappear automatically.

 

As I understand offseting by up to 7 pixels left or right would do the trick .

something like this line from TheMoles example scroll

 

VDP_SET_REGISTER(VDP_REG_SIT, backbuffer_sit);

 

it would cause wrap around to the other side. I suppose I could leave a blank column.

 

From what I read I could load mutliple name tables into memory but that would not support the curent scroll method so just wrap around horizontal scrolling would most like like suffice.

 

 

Interesting perception. I'm curious what you are basing that information on? To date there are about 400 F18A boards out in the wild, and probably close to half were sold with tall-pins (which typically means it went into a CV).

Since you already have tile-based scrolling, then using the F18A's scroll registers to get smooth pixel scrolling could be as simple as adding seven VDP calls in your game loop between the tile updates. However, with pixel scrolling you have to have tiles ready to be scrolled in, which means either masking a row or column (depending on vertical or horizontal scrolling), or using multiple name tables. Using multiple name tables allows you to have the whole screen for scrolling, and either way you need an extra name table in VRAM.

[matthew180]

I don't mean any offence by that and that sounds great . I'm referring to colecovision install base only and not overall. If it's not like %80 of current colecovision users so I would not want to make a game that didn't support both the stock system and the enhanced system.

No offense taken, it is just interesting to me how people form their impressions and opinions. I don't think it is possible to really know how many CV users there are out there, especially now in this day and age these communities are always in flux. If Bmack's recent poll is any representation of the community, then it appears about 30% of the people who answered the poll are running an F18A.

 

It also depends on your goals while making the game. If you are creating it to make money, then certainly supporting the stock VDP would be very important at this time. If you are doing it primarily for enjoyment, then supporting the F18A's enhanced features is less of an issue.

 

 

But I am certainly interested in adding support for it. It would also fix the 4 sprites per line when I have some bullets or sprites disappear automatically.

Yes it does fix the 4 sprite limit. You get that enhancement for free. Anyone running your game on an F18A will get 32 sprites on a line, flicker free (unless you implement sprite rotation).

 

As I understand offseting by up to 7 pixels left or right would do the trick .

something like this line from TheMoles example scroll

 

VDP_SET_REGISTER(VDP_REG_SIT, backbuffer_sit);

 

it would cause wrap around to the other side. I suppose I could leave a blank column.

Leaving a blank column is not really going to give you the results you want, IMO. At the very least you should make a mask via the 2nd tile layer (Tile Layer 2 or TL2).

 

From what I read I could load mutliple name tables into memory but that would not support the curent scroll method so just wrap around horizontal scrolling would most like like suffice.

I think you can use multiple name tables with your current scrolling system. I assume you are currently scrolling by shifting tile columns 1..31 to the left (to positions 0..30), then writing the new data for column 31.

 

Using multiple name tables, you simply have the data for the new column (what will become column 31) in the 1st column of the second name table. This new column data gets scrolled into view during the pixel scrolling. When you reach scroll pixel 7, you do the same tile adjustment you are currently doing: reset the pixel scroll to 0, adjust the tile columns to the left, update column 31 with the new tiles (the same tiles that just scrolled in from the 1st column of the second name table), then update the 1st column of the second name table with the new column tiles to be scrolled in.

 

So basically you have one extra VDP register to deal with, and 32 extra bytes of VRAM to write each time you do a tile-level adjustment. It does mean you have a second full name table sitting there just to support a single column, but you can use the rest of the name table for other data storage if you like (however since you are dealing the columns the memory would be cut up into 31-byte chunks).

 

You can also use the 1st and 31st columns of the second name table to support full-screen left and right scrolling. This would require a little more VDP register work though, but certainly doable.

Edited September 10, 2016 by matthew180

[digress]

It currently does scroll left & right. I found it necessary for doing loops but the goals are to the right usually but you might have to back track.

 

yes 1..31 moved to 0-30 then draw the new column. It actually gets the new column from the hidden second name table. Then I load a new hidden name table when I go from 31 back to 0 for the next scene

 

I think you can use multiple name tables with your current scrolling system. I assume you are currently scrolling by shifting tile columns 1..31 to the left (to positions 0..30), then writing the new data for column 31.

 

 

This below sounds like it's exactly what i've already done.

 

Except for the pixel level offset adjustment which I can't do yet. So first thing. I need to get an f18a so I'll be able to test it. Then I'll have to get ... it! I'm almost completely unfamiliar with what this can do. ... just did that... Order Number: 400. Sounds like your numbers are correct.

 

If the demos are any example then it looks like the tiles could use cm1 or cm2 or something with more colours ?

 

The main thing I need now is how to impletment the offset in c-language for colecovision.

 

Using multiple name tables, you simply have the data for the new column (what will become column 31) in the 1st column of the second name table. This new column data gets scrolled into view during the pixel scrolling. When you reach scroll pixel 7, you do the same tile adjustment you are currently doing: reset the pixel scroll to 0, adjust the tile columns to the left, update column 31 with the new tiles (the same tiles that just scrolled in from the 1st column of the second name table), then update the 1st column of the second name table with the new column tiles to be scrolled in.

 

So basically you have one extra VDP register to deal with, and 32 extra bytes of VRAM to write each time you do a tile-level adjustment. It does mean you have a second full name table sitting there just to support a single column, but you can use the rest of the name table for other data storage if you like (however since you are dealing the columns the memory would be cut up into 31-byte chunks).

 

You can also use the 1st and 31st columns of the second name table to support full-screen left and right scrolling. This would require a little more VDP register work though, but certainly doable.

 

Using multiple name tables, you simply have the data for the new column (what will become column 31) in the 1st column of the second name table. This new column data gets scrolled into view during the pixel scrolling. When you reach scroll pixel 7, you do the same tile adjustment you are currently doing: reset the pixel scroll to 0, adjust the tile columns to the left, update column 31 with the new tiles (the same tiles that just scrolled in from the 1st column of the second name table), then update the 1st column of the second name table with the new column tiles to be scrolled in.

 

So basically you have one extra VDP register to deal with, and 32 extra bytes of VRAM to write each time you do a tile-level adjustment. It does mean you have a second full name table sitting there just to support a single column, but you can use the rest of the name table for other data storage if you like (however since you are dealing the columns the memory would be cut up into 31-byte chunks).

 

You can also use the 1st and 31st columns of the second name table to support full-screen left and right scrolling. This would require a little more VDP register work though, but certainly doable.