Destroyer - game in development

[sometimes99er]

Man... This is looking awesome. I might not even enter my piece of crap XB offering now. You really do some nice stuff, man.....

Thank you. And phew! ... now I know my efforts didn’t discourage you, but maybe inspired you. Good to see you put up your own topic. I’ll try and help as much as I can.

 

[sometimes99er]

One question, how did Karsten add all those videos? Is that an available feature on this forum?

Apparently Flash is not available, so I converted Flash animations to GIFs. I haven’t tried too many media types, but I see you got YouTube working alright.

 

[sometimes99er]

Yeah, letting the ship lay low in the water would have been cool. But the game will be nice without that feature nonetheless.

Perhaps the ship could start burning when it takes too much damage or you could change the shape of the ship.

Looking forward seeing the explosions.

 

Hope this doesn't all sound to cruel being in the X-mas spirit and such

Yes, I’ve been thinking about what should happen when a game is close to the end. The ship could break in two, sink and slowly vanish. It could also sink with only pixels above the water being visible. It could have series of explosions.

 

[sometimes99er]

Okay, it came down to these two. The latter doesn’t need sprite support, so obviously a bit easier to do (less code and less data). I think it also works fine in the corner of the eye, and with the increasing alarm you’ll know what’s happening.



Back in the eighties I did an assembler game for the TI-99/4A’s Mini Memory, a clone of Missile Command, and it had these very similar explosions (the game is lost today). I’ve doubled the number of animation frames from 8 to 16. I might execute them a bit slower. I’ve tried and play around with colors, starting out with dark red, and having a somewhat psychedelic experience. I might try out all bright red through all the frames instead.

Edited October 30, 2014 by sometimes99er

[+retroclouds]

The damage indicator is nice, as are the explosions. Very cool

 

Perhaps you could try to do the first frames in white and the ending ones in bright red.

Think like white flash turning red.

[sometimes99er]

The damage indicator is nice, as are the explosions. Very cool

 

Perhaps you could try to do the first frames in white and the ending ones in bright red.

Think like white flash turning red.

Thanks.

 

Well, final damage indicator will change color. First dark green, then dark yellow and finally dark red for the entire bar as it increase in width.

 

 

The explosion may appear a bit too squarish (frame 8 thru 13). Driving up the frame rate seems to help. And then this little devil takes 512 bytes for the patterns alone !

 

Will be looking into title screen music now.

 

Edited February 21, 2014 by sometimes99er

[Opry99er]

Lookin great man!!!

[+acadiel]

I am anxiously awaiting this game. Great job so far!!!!!!!

[sometimes99er]

Tried to do Green Day’s 21 Guns. Quickly realized it had to be more soft to resemble anything. Tried and add extra rests. Then went for two simple sets of ADSR (Attack, Decay, Sustain and Release). It’s not really convincing.

http://sometimes.planet-99.net/destroyer/0033.mp3

Will try something completely different.

Edited October 30, 2014 by sometimes99er

[Opry99er]

I like the sounds there, my brother. Keep us updated on your musical progress, as that is a dear subject to me. Additionally, Marc Hull has just completed his SIDBlaster99 card. All kinds of insane sh** possible with that card. You should check it out

[sometimes99er]

I like the sounds there, my brother. Keep us updated on your musical progress, as that is a dear subject to me. Additionally, Marc Hull has just completed his SIDBlaster99 card. All kinds of insane sh** possible with that card. You should check it out

Thanks mate. Well, I like many of the later singles with Green Day. I thought this 21 Guns would support the war theme of the game, but now I don’t. Will be working on these ...

 

• Title music
  
• Sonar sound
  
• Depth charge dropout
  
• Ship engines
  
• Ship explosion
  
• Damage alarm
  
• End of game explosion
  
• End of game tune
  
• Surface explosion
  
• Missile launch
  
• Sub explosion
  

In the future I better just attach mp3 rather than include it with the site media tag.

 

[+retroclouds]

I like the sounds there, my brother. Keep us updated on your musical progress, as that is a dear subject to me. Additionally, Marc Hull has just completed his SIDBlaster99 card. All kinds of insane sh** possible with that card. You should check it out

Thanks mate. Well, I like many of the later singles with Green Day. I thought this 21 Guns would support the war theme of the game, but now I don’t. Will be working on these ...

 

• Title music
  
• Sonar sound
  
• Depth charge dropout
  
• Ship engines
  
• Ship explosion
  
• Damage alarm
  
• End of game explosion
  
• End of game tune
  
• Surface explosion
  
• Missile launch
  
• Sub explosion
  

In the future I better just attach mp3 rather than include it with the site media tag.

 

 

 

I wonder if any of the free samples at http://www.freesound.org would be of any use.

 

Somehow if I see the Destroyer, I have to think about the 80's arcade game 1942 when it plays

the military drums on title screen when inserting coin .....

 

[edit] Man, I searched for some matching songs, and now I have the U96 theme "Das Boot" running in my head, horror. Sorry couldn't resist

[sometimes99er]

Somehow if I see the Destroyer, I have to think about the 80's arcade game 1942 when it plays

the military drums on title screen when inserting coin .....

 

[edit] Man, I searched for some matching songs, and now I have the U96 theme "Das Boot" running in my head, horror. Sorry couldn't resist

He he, you knew I was going to work on some military drums. I hope to do better than 1942.

 

 

Ill be working with snare notes with limited amount of accent. The custom player routine will then have really simple ADSR and a fixed random seed stream variation. I can then try different seeds to hopefully get something believable. If this does not turn out acceptable - considering the amount of bytes used, then Im back with the more ordinary music. I think its got to be upbeat, since tones held for long quickly seem to irritate my almost sensitive ears.

 

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

 

Edited February 21, 2014 by sometimes99er

[sometimes99er]

This is the layout of the character set. There will be different colors for title screen, main game and end of game.

 

 

The dynamic area consist of subs that move smoothly left and right and at different speeds. The last part of this area contains the clouds.

 

This is of course just a snapshot of VDP memory in use (ROM will look different).

 

Edited February 21, 2014 by sometimes99er

[Opry99er]

Damn, son!! I'm impressed... How did you implement your character set?? Are there TI fonts available for DL? I posted a question in my "Honeycomb Rapture" thread about character sets/fonts... But I think maybe I wasn't clear... I would like to find a way to load a new graphic character set into low memory for XB to draw from during my game....

[sometimes99er]

Damn, son!! I'm impressed... How did you implement your character set?? Are there TI fonts available for DL? I posted a question in my "Honeycomb Rapture" thread about character sets/fonts... But I think maybe I wasn't clear... I would like to find a way to load a new graphic character set into low memory for XB to draw from during my game....

Thanks. Well, I use different approaches. Maybe I’ll make some YouTube tutorials someday. In this case I started out with a copy of the standard characters for reference. I think I got these characters from the Game Boy (sorry, I don’t know who to credit). This was done months ago. When work started on Destroyer, I pulled this one out and then adjusted quite a few of the characters. Only today I retouched M and W.

 

 

I think I have about 60 fonts in a 64x256 pixel graphic layout. Each of these can then easily be put thru my Grapefruit utility (Windows) and output assembler or basic statements. The download at my site has several examples included. I’ll happily supply you with more to play around with.

 

Since I picked up the TI-99/4A again, I mostly use cross assemblers with binary output, so I don’t know much about object code, interaction with XB etc., but I guess there’s already TI utilities for doing what you suggest.

 

Edited February 21, 2014 by sometimes99er

[sometimes99er]

For this phase colors, graphics, layouts, overall actions and priorities are identified. The next phase is routines and tests. Ill detour for a few sound experiments on the way. Next phase will be tying things together and tuning. Finally the last phase is mainly out of the box, such stuff as manual and art, and then probably a bit of fine tuning.

 

I dont have access to the real hardware, so any testing and feedback will be appreciated.

 

 

Below some of the updated character and sprite designs ...

 

Edited February 21, 2014 by sometimes99er

[+retroclouds]

For this phase colors, graphics, layouts, overall actions and priorities are identified. The next phase is routines and tests. I’ll detour for a few sound experiments on the way. Next phase will be tying things together and tuning. Finally the last phase is mainly “out of the box”, such stuff as manual and art, and then probably a bit of fine tuning.

 

I don’t have access to the real hardware, so any testing and feedback will be appreciated.

 

 

Below some of the updated character and sprite designs ...

 

 

Interesting stuff

Just out of curiosity. How do you test the animations and convert them to patterns ?

Have you written an own converter for that ?

[sometimes99er]

Interesting stuff

Just out of curiosity. How do you test the animations and convert them to patterns ?

Have you written an own converter for that ?

Thanks. Often Im learning and trying out new software and techniques as I go along.

 

The explosion itself was hand drawn on screen using mouse with a paint program (PaintShopPro) with zoom factor at maybe 4 or 5:1. I then copied the first 16x16 pixel frame onto the same sheet, next to the last frame and adjusted the new one a bit. This is how I continued. I did not know how well it would do, until I took all 16 frames, converted to hex and wrote the 2005.03.19 Space Invaders demo. Yes, Ive been reusing some old graphics of mine. I do intent to try and better the explosion though.

 

 

The depth charge design, spin, launch and water splash was also hand drawn using mouse, but with an animation program (AnimationShop). I start out with a static background from the game draft. This is then duplicated for the next 100 frames. First frame nothing. Second frame, I draw the top of a barrel coming up or out of the ship. Third frame, I started drawing a barrel at its next position. I use the arrow keys to quickly go back and forth between frames. I ended up having a total of only 15 frames. I then video-taped (CamtasiaStudio) myself tapping the arrows keys in both directions.

 

Lately I tried and import different TI graphic objects into Flash (Adobe) and could easily move them about etc. using the built-in ActionScript2 (syntax like Javascript). Using layers I simply put the ship and the border on top of the clouds and then adjust the position of the clouds (wider than the screen) once in a while with something like clouds._x = clouds._x + 2.

 

To go from graphics to assembler data statements I use my own Grapefruit utility.

 

Edited May 7, 2015 by sometimes99er

[+retroclouds]

Thanks for the detailed description on how you proceed. That is very interesting stuff.

 

Lately I tried and import different TI graphic objects into Flash (Adobe) and could easily move them about etc. using the built-in ActionScript2 (syntax like Javascript). Using layers I simply put the ship and the border on top of the clouds and then adjust the position of the clouds (wider than the screen) once in a while with something like clouds._x = clouds._x + 2.

 

Oh on a sidenote, did you know a TMS9918 VDP implementation was done in javascript (using canvas for drawing).

It's part of an MSX emulator written in javascript. Check here

I have some plans for doing a utility that will be using this VDP implementation.

 

As far as the RGPC naming is concerned, no use in changing its name now, with only a few more weeks remaining

[sometimes99er]

Oh on a sidenote, did you know a TMS9918 VDP implementation was done in javascript (using canvas for drawing).

It's part of an MSX emulator written in javascript. Check here

I have some plans for doing a utility that will be using this VDP implementation.

No, never saw that one. Thanks. Amazing what JavaScript can do these days. Did you see JatoBAS. Also TMS9918A emulation in JavaScript.

 

Last year Shiru did the SN76489 (TMS9919) in ActionScript3. The source is only 229 lines. It sounds very true.

 

There’s also a ZX Spectrum emulated in Flash.

 

Bottomline. Some amazing TI related online utilities and emulation should be possible with both languages.

 

[sometimes99er]

Moving along nicely. ROM consumption at 21%.

 

I took a look at data compression routines. Compression time is not an issue. Data will be compressed before we create the ROM. Decompression time is usually not an issue. I’m trying to steer clear of the need for 32K RAM Expansion, so I won’t actually have any “workspace”. I need to decompress nicely in a rollout manner directly to VDP. The more exotic compression techniques seem to work best with 2K chunks and up. Also a decompression routine takes space too.

 

ScratchPad has 32 bytes for CPU workspace and 32 bytes for stack of return addresses. So there’s 192 bytes left for controlling all the action.

 

Simple RLE on my main static character patterns alone reduces data size from 728 bytes to 466. This would work nicely on several other data chunks. The submarines and clouds will have to stay uncompressed in ROM as we need clean sources to do effective software scrolls (at least I think so). And remember we’re not “just” scrolling in one or another direction.

 

One large preliminary setup of VDP (setting several screens, color sets, sprite lists and patterns) using decompression might be an idea.

 

[sometimes99er]

These are "real" clouds resized and polished a bit. I didn't like the "one pixel" holes in the clouds.

 

 

The image size is 384x16 pixels. The TI-99/4A screen is 256 pixels wide, so the clouds shouldn't have a too obvious wrap-around effect.

 

Edited February 21, 2014 by sometimes99er

[+retroclouds]

Moving along nicely. ROM consumption at 21%.

 

I took a look at data compression routines. Compression time is not an issue. Data will be compressed before we create the ROM. Decompression time is usually not an issue. I’m trying to steer clear of the need for 32K RAM Expansion, so I won’t actually have any “workspace”. I need to decompress nicely in a rollout manner directly to VDP. The more exotic compression techniques seem to work best with 2K chunks and up. Also a decompression routine takes space too.

 

ScratchPad has 32 bytes for CPU workspace and 32 bytes for stack of return addresses. So there’s 192 bytes left for controlling all the action.

 

Simple RLE on my main static character patterns alone reduces data size from 728 bytes to 466. This would work nicely on several other data chunks. The submarines and clouds will have to stay uncompressed in ROM as we need clean sources to do effective software scrolls (at least I think so). And remember we’re not “just” scrolling in one or another direction.

 

One large preliminary setup of VDP (setting several screens, color sets, sprite lists and patterns) using decompression might be an idea.

 

 

 

Now, that is what I call interesting stuff

 

As the clouds will move rather slowly would having a decompressed version in VDP

be an option ? You could work on it in "parts" divided accross multiple frames and once

complete, move it into the pattern table.

 

Then again, such logic would also take some code space to implement.

 

What I did in the cartridge version of Pitfall was to "page-out" certain parts of scratch-pad memory to the VDP,

use the new free space as work-buffer and when finished "page-in" into scratch pad again. That works pretty well.

 

However, I did not use any compression techniques in Pitfall! so looking forward learning on how you proceed

[sometimes99er]

As the clouds will move rather slowly would having a decompressed version in VDP be an option ? You could work on it in "parts" divided accross multiple frames and once complete, move it into the pattern table.

Yes, the clouds will initially move slowly in one direction (less than 1 pixel per frame). The movement of the ship will affect the clouds, not on a 1:1 basis, but I want it to be noticeable. Somewhat erratic clouds would maybe make a nice twist/effect. Clouds are about the only thing I plan not to update every frame. Nothing will move too smoothly anyway since all horizontal motion is being calculated with fixed decimals. Bottomline ... The plan is to take two bytes of cloud pattern from ROM, shift it into place and put one byte to the VDP. Then repeating the process until done. Will probably wait one or two frames for it to “settle” before clouds are again being updated.

 

What I did in the cartridge version of Pitfall was to "page-out" certain parts of scratch-pad memory to the VDP, use the new free space as work-buffer and when finished "page-in" into scratch pad again. That works pretty well.

I think I’ll just keep certain things in VDP. One example could be the score.