Okay, Kerm, I tested it for about an hour last night, and here are all my opinions:

- I hope you know the AI is still pretty much a WIP at this point, because the highest difficulty can't get me out of green health, even after ~50 attempted shots.

- The [MENU] glitch that changes the palette to 3 bit color is a bit annoying -- did you find any fixes yet?

- The wind has little or no purpose at the moment, it doesn't seem to affect my shots at all -- either that, or you need to just make the speed of wind range to higher values Smile

- The playing field is a bit cramped IMHO. 4x smaller tanks would do true wonders.

- The explosion isn't good as black, I would make it red or orange Smile
AI: I know.
MENU: JosJuice found a syscall, but it's not accessible via the SDK yet. I'll nag Jonimus.
Wind: I reduced the strength to zero for debugging
Cramped: orly? It didn't feel cramped to me. I'll look forward to seeing if others agree
Explosion: I'd be open to trying other colors.
I personally thought it was a bit cramped, but that's just personal opinion Smile though however, I think many will agree that black isn't a good color choice.
KermMartian wrote:
MENU: JosJuice found a syscall, but it's not accessible via the SDK yet. I'll nag Jonimus.
No. Contrary to popular belief, I haven't really done anything useful for the Prizm. At least not finding syscalls. Razz
JosJuice: Whoops, it was Qwerty then, my mistake. Wink Ashbad: I'm trying and failing to remember what color Scorch2000 used; I'll have to play it again and find out.
It did feel a little cramped to me with anything over 3 or 4 tanks depending on the terrain. The other thing is it would be easier if shift was the primary key instead of exe. Also I would scale down the maximum power of shots because I often find myself shooting in straight lines even for distant enemies. Just wondering, but did that menu background image take up half the file size?
More than half the size, 165,888 bytes of the 209-odd kilobytes. Smile And the other graphics and sprites took up most of the remainder; I'd say the actual gameplay isn't more than 20K or 30K of code. Tari is at some point going to look at possible compression methods that would be small and fast for me to implement, since the main menu splashscreen has a lot of repetition in terms of large blocks of colors and not a giant palette. Smile Yup, I can scale down shot power, and I'll see what a smaller tank looks like.
Perhaps you could try 256 colors with a palette. As a note increasing the complexity of the terrain would keep it less crowded and make gameplay more interesting. Most of the time I get an almost flat map. Also the AI has an obsession with shooting its self Sad
I could, but that might ruin the nice gradient on the letters. I suppose a 256-color -> 2-byte color would take at most 512 bytes of memory and reduce the size from 165,888 to 512 + 82,944 = 83,456 bytes. I'll definitely give that a try tomorrow. Yeah, the randomness routine works slightly less well than on the z80s for terrain generation; my to-do list has long had an item to do something about that, and I might try to do something about that before sleep tonight. I'm trying to re-check the AI aiming math that I worked through for the z80 version to see if I made any errors porting it over to C, most likely an obsolete comment that I forgot to change when I made an algorithmic correction.

Edit: Improved terrain, trying to improve it more; now it's looking too sawtoothed. Adding a third-derivative damping factor. I noticed that the AI only fails when shooting in the positive X direction, so that narrows down my debugging.
I like it a lot. A couple of things I noticed, though:

1) It's possible to get into positions where the opponent's aiming algorithm glitches and can't hit you. If you're very low and the enemy is nearby horiizontally, but very high above you vertically, this will happen. It tries to shoot horizontally, but it actually needs to shoot more vertically.

2) The AI likes to commit suicide by shooting straight up in the air. Not sure what that's about, but it makes it a lot easier :p

3) The Menu glitch is still there, even though I know that's not your fault.

4) The aiming thing could use a some fine control buttons, because a 2-3 degrees can sometimes miss the tank to either side and it's difficult to aim more precisely than that.
It is a good thing I checked Cemetech yesterday, else I would probably have missed the beta link on page 3...

Anyway I tried it and it looks pretty great. I only noticed some glitches with AI, like opponents blowing themselves up, and restarting the game causes it to turn into 3 bit color mode instead of 16, but it's not finished yet anyway, plus it was still fun.

I made a video of the game in action, for those who lacks a Prizm:

Thanks for doing that, Kevin! To be sure, the AI is very far from finished, and I'd go so far as to say it's more or less useless at the moment. I think I still have a few terrain corrections, too; I didn't like that first flat map you got too much.

Edit: An Obliterate beta is finally ready! We have working AI, cool-looking explosions, working wind, and nice terrain, on top of all the existing features. I'll take a video now and post a news article in the next hour or two.
Kerm, the Bdisp_EnableColor has been in libfxcg for a while, I added it as soon as qwerty told me about it. Let me know if you can't get it working and I'll check if I have it all setup correctly, and yes I know the headers still need some organization. Sad
KermMartian wrote:
I could, but that might ruin the nice gradient on the letters. I suppose a 256-color -> 2-byte color would take at most 512 bytes of memory and reduce the size from 165,888 to 512 + 82,944 = 83,456 bytes. I'll definitely give that a try tomorrow.


I'm currently in the process of making a C routine that will draw PNG encoded data to the screen -- PNGs can be more than half the size of the original image (if I achieve my rendering routine correctly). I'm writing it to use any mode possible for compression, so I'm skipping the Adam7 interlacing and going with the lowest-standard method I can find. And, if you specify it at creation (I'll provide a Ruby script that will format the image data) you can even index it to a limited palette, so pictures like yours which seem to use less than 256 colors can be compressed even further.

For now, 200K for an Add-in really isn't that bad, considering most people like me only really have 3-4 3rd party add-ins and most of the storage space left. I'll give you a call once I have everything working and we can bust some bytes Wink
Hehe, sounds good. I might give the 256-color palette a try if you get stuck on your image compression algorithm though, and see how it goes.
*bump* So why did I never complete this game? Was I waiting for the color fix? Sad
I have no clue Kerm, progress just seemed to disappear on it, I think minecraft may have been involved.
KermMartian wrote:
Wind: I reduced the strength to zero for debugging
I'm likely late to the party on this one, but would it be hard to add a second trajectory that ignores wind? Then compare the two post-shot side by side?
I played through a few games now, and wind and everything seems to work. It looks like the color issues are the only thing left, and with the new PrizmSDK (see the front page news!) it might actually be fixed as well.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 4 of 4
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement