Jump to content
IGNORED

Destroyer - game in development


sometimes99er

Recommended Posts

I know I'm a little late to the discussion, but I wanted to throw in my two cents about the damage meter. Military ships are compartmentalized internally and have water tight doors in all the bulkheads. This lets the ship isolate and seal off damaged parts and control flooding. I think having something like 4 bulkhead doors shown at the top would be appropriate, and split the ship into 4 parts: fore, aft, and two mid segments. Then, for example, a hit to the aft would show that door as destroyed, but another hit to the aft would not affect the ship. Once the ship has been hit in all 4 segments, it sinks. For each destroyed door you could show the ship lower in the water as each section would be flooded.

 

Just an idea. The game is looking really nice!

 

Matthew

  • Like 1
Link to comment
Share on other sites

I know I'm a little late to the discussion, but I wanted to throw in my two cents about the damage meter. Military ships are compartmentalized internally and have water tight doors in all the bulkheads. This lets the ship isolate and seal off damaged parts and control flooding. I think having something like 4 bulkhead doors shown at the top would be appropriate, and split the ship into 4 parts: fore, aft, and two mid segments. Then, for example, a hit to the aft would show that door as destroyed, but another hit to the aft would not affect the ship. Once the ship has been hit in all 4 segments, it sinks. For each destroyed door you could show the ship lower in the water as each section would be flooded.

 

Just an idea. The game is looking really nice!

 

Matthew

Thanks. And thanks for your input. I like the ideas. Much appreciated. I might try out something with bulkhead doors or something. Maybe Ill have to read up on warships.

 

A limited run of undocumented code with photos of empty bottles of redwine will be available at an estimated $199.90. All copies will of course be signed.

 

0040.jpg

icon_shades.gif

Edited by sometimes99er
Link to comment
Share on other sites

Very nice. So does this mean a cartridge EPROM is planned ? Would love to play this game on my barebone console I have in my living room :D

Thanks.

 

Not really. The virtual ROM should of course be ready at the end of the month. I hope to do a manual and some concept cover art too. At that point anybody can do EPROMs etc.

 

:)

Link to comment
Share on other sites

He he. Beer sometimes boosts your creativity (strange fact). And graph paper is your flexible friend. This is how I used to draw TI graphics - and still do (during meetings, telephone conversations etc. - it’s in my blood). Sorry about my “pink” uni-ball eye needle point pen. Bought a lot on sale and been running out of the darker violet ones.

 

0043.jpg

Edited by sometimes99er
Link to comment
Share on other sites

He he. Beer sometimes boosts your creativity (strange fact). And graph paper is your flexible friend. This is how I used to draw TI graphics - and still do (during meetings, telephone conversations etc. - it’s in my blood).

 

I remember doing the same, during class when I was in high school. And then writing out the hex code for character definition from memory (made easier when I figured out that the hex values of the pixel clusters, which were themselves binary, were an actual number system).

 

post-24935-12633904298_thumb.jpg = binary "0101" = decimal "5" = #0005 (or just "5" in a CALL CHAR statement).

 

When I learned how to easily convert binary to decimal, I no longer needed the chart from page III-5 of the "User's Reference Guide," which I had carried around with me until I made the pixel-binary connection. I still remember the moment I made the connection, in computer "math" class, when the teacher was discussing non-decimal number systems. She did a comparison of binary, decimal and hex, while I was looking at page III-5, and "click!"

 

In my defense, until then, I'd never heard of base-16 counting, only knew of binary as "off/on" instead of "0/1," and I've always been horrible with math and numbers (hence why I was taking a programming class that counted as a math class credit).

  • Like 1
Link to comment
Share on other sites

He he, I think the last thing I had trouble with back in the heyday was to distinguish B and D.

 

0045.png

 

Been cleaning up some code. ROM consumption at 42%.

 

>0000 - >02ff screen #1 title
>0300 - >031f character colors
>0380 - >03ff sprite list
>0400 - >06ff screen #2 game
>0800 - >0aff screen #3 the end
>1000 - >17ff character patterns
>1800 - >1fff sprite patterns

icon_smile.gif

Edited by sometimes99er
Link to comment
Share on other sites

I've noticed that you have the SAT right before the screen tiles.

 

I have been studying Colecovision Galaxians and they have a similar VDP setup.

 

SAT at >1B80

Tiles at >1C00

 

It allows them to write updated sprites AND tiles, without having

to set the VDP write address twice. That's kinda cool :cool:

 

oh, are still planning on having a seabed in the game ?

 

Looking forward seeing more ;)

  • Like 1
Link to comment
Share on other sites

I've noticed that you have the SAT right before the screen tiles.

 

I have been studying Colecovision Galaxians and they have a similar VDP setup.

 

SAT at >1B80

Tiles at >1C00

 

It allows them to write updated sprites AND tiles, without having

to set the VDP write address twice. That's kinda cool :cool:

 

oh, are still planning on having a seabed in the game ?

 

Looking forward seeing more ;)

When doing the cloud scroll routine, my first priority was to use VDP using auto-increment. As you say, we then won’t need to set VDP write address more than once. For the cloud scroll there’s no need for RAM, just get data from ROM, scroll and put it to the VDP (using auto-increment). The CPU slice is considerable with boundary checks etc. A super effective CPU routine demands pre-scrolled and wraparound data. Original cloud data size is 16*256/2*3/8 = 768 bytes. Optimal speed (somewhat limited rollout) would require 768/3*5*8 = 10240 = 10K of ROM data.

 

I’m considering changing cloud width from 384 to either 256 or 512. This would make boundary handling easier, smaller and most importantly quicker. A width of 256 would however introduce a cloud wraparound feel.

 

The seabed will consist of scrolling characters and 3 sprites, allowing for depth charges to reach the seabed. Sprites will be 16 pixels high and characters 8 pixels high. Sprites will depict shipwrecks, anchors, rocks etc. I think the characters could be horizontally reduced a bit like the mountain scrolling seen in Moon Patrol (TI-99/4A).

 

I’ve decided to only have depth charges come out on the right side of the destroyer. With joystick control I was considering alternating depth charges from left and right, but since there’s a delay between launches this might be a frustrating element when the heat is on. The destroyer has been moved 8 pixels to the left to accommodate a bit. Still the ship has to be defended against torpedoes, so it has to be centred.

 

There’s a serious overall speed limit since we can’t have depth charges and torpedoes going off screen too much. The player should not be allowed to just move a torpedo off screen and then forget about it. We could use simple wraparound or a system controlling a maximum of pixel off screen. This would allow for torpedoes, depth charges and even subs to reappear (if appropriate). If the offset gets to big, then a sprite would go back into the ready pool.

 

:cool:

Link to comment
Share on other sites

Regarding the clouds; as this is a graphics mode 1 screen. Would it be possible to unroll the cloud patterns to the VDP before game start (while screen is off) ? You still have about 8K free space between >2000->3FFF, guess you could save on ROM space when combined with 256 clouds width.

 

During gameplay you then copy the patterns from VDP memory into the pattern table.

Dunno if that would be fast enough though, then again clouds move slowly :ponder:

 

Yes, there are quite some challenges when writing a game like this.

Dealing with velocity, handling game parameters/screen boundaries, etc.

 

This is interesting stuff :cool:

  • Like 1
Link to comment
Share on other sites

Regarding the clouds; as this is a graphics mode 1 screen. Would it be possible to unroll the cloud patterns to the VDP before game start (while screen is off) ? You still have about 8K free space between >2000->3FFF, guess you could save on ROM space when combined with 256 clouds width.

 

During gameplay you then copy the patterns from VDP memory into the pattern table.

Dunno if that would be fast enough though, then again clouds move slowly :ponder:

 

Yes, there are quite some challenges when writing a game like this.

Dealing with velocity, handling game parameters/screen boundaries, etc.

 

This is interesting stuff :cool:

Thanks for the input.

 

Well, I wouldn’t wanna move (read and write) large chunks of data around in VDP (I think my scroller as is could compete with that). I could have all the 10K cloud patterns unrolled in 32K RAM Expansion, but I’ve chose not to use that (the expansion that is). It’s a speed trick to remember though.

 

Redefining the location of the character pattern table and then having all 8 pixel positions in VDP is not feasible, or so I think. The location has to increase with 2K at a time, so having all 8 pixel position to swap between will use all of the available 16K. I have to copy other characters to each location and then wouldn’t know where to put the screen(s) and sprite patterns. With careful initial planning this might be a nice trick to use with another game.

 

Again, as you say, clouds move slowly, and will be affected by both ship movement and acceleration, so some erratic impression is unavoidable. I’m updating clouds vertically (yes, I started out horizontally), so the 2 lines of characters won’t slip (like dividing the clouds in 2 separate moving chunks). I think Parsec updates vertically too. Clouds will hide the vertical slips better.

 

He he, I never thought of it like this - “8K of wasted VDP space” ...

 

:)

Link to comment
Share on other sites

... as this is a graphics mode 1 screen.

Yes, I knew from the start that I would use quite a few sprites, and since hearing about a sprite repeat problem with bitmap and hybrids on the real deal, I thought that this game should have a chance of running on almost any TI-99 (except version 2.2) without too many problems/modifications. So graphic mode 1 was chosen early on. Anyone got more news on this sprite repeat problem ?

 

:!:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...