sometimes99er Posted January 6, 2010 Author Share Posted January 6, 2010 (edited) Closeup of package (European version) ... Edited February 21, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
matthew180 Posted January 6, 2010 Share Posted January 6, 2010 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 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 6, 2010 Share Posted January 6, 2010 Closeup of package (European version) ... 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 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 7, 2010 Author Share Posted January 7, 2010 (edited) 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. Edited February 21, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 7, 2010 Share Posted January 7, 2010 Hahaa... What the hell is this?! 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 7, 2010 Author Share Posted January 7, 2010 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 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 7, 2010 Share Posted January 7, 2010 Man--- great stuff! Check out my thread later today... Got some good stuff to add... If I can get the time to do it up. I love your title screen, man... Can't wait to order a cart from ya! 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 9, 2010 Author Share Posted January 9, 2010 Probably a bit behind schedule. ROM consumption at 32%. Adding seabed. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 10, 2010 Share Posted January 10, 2010 Pictures, pictures!!! 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 12, 2010 Author Share Posted January 12, 2010 (edited) Been tuning (~ playing around with) overall velocity control routine. Now I'm reorganizing and optimizing cloud scroll routine. ROM consumption at 36%. Edited February 21, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
+acadiel Posted January 12, 2010 Share Posted January 12, 2010 Been tuning (~ playing around with) overall velocity control routine. Now I’m reorganising and optimising cloud scroll routine. ROM consumption at 36%. I like the programming aid that you have there :-) 1 Quote Link to comment Share on other sites More sharing options...
InfernalKeith Posted January 12, 2010 Share Posted January 12, 2010 That's it! The missing ingredient in my coding work! I must add that cold, round, 12-ounce peripheral to my system immediately. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 12, 2010 Share Posted January 12, 2010 Looks like my thread... . love the graphing paper.... And the beverage. 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 13, 2010 Author Share Posted January 13, 2010 (edited) 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. Edited February 21, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
TI99Kitty Posted January 13, 2010 Share Posted January 13, 2010 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). = 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). 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 15, 2010 Author Share Posted January 15, 2010 (edited) He he, I think the last thing I had trouble with back in the heyday was to distinguish B and D. 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 Edited February 21, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 15, 2010 Author Share Posted January 15, 2010 (edited) Here was 0.3 demo MESS cartridge ... Edited May 7, 2015 by sometimes99er Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 15, 2010 Share Posted January 15, 2010 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 oh, are still planning on having a seabed in the game ? Looking forward seeing more 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 16, 2010 Author Share Posted January 16, 2010 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 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. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 16, 2010 Share Posted January 16, 2010 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 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 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 16, 2010 Author Share Posted January 16, 2010 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 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 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” ... Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 16, 2010 Author Share Posted January 16, 2010 ... 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 ? :!: Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 21, 2010 Author Share Posted January 21, 2010 (edited) Any resemblance to any item living or dead is purely coincidental. Edited February 21, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
InfernalKeith Posted January 21, 2010 Share Posted January 21, 2010 Beautiful!!! 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 21, 2010 Share Posted January 21, 2010 Very very cool! "Best performance with MESS. Only for use in Europe" .... Did you notice? this is post#100 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.