Thursday, April 22, 2010
Work... work...
Last few weeks I've been experimenting with some possible drastic means of optimization, including multi-threading and frame buffers. Both of those ended up being wild goose chases, but in the process I learned a heck of a lot, and ended up making some other great changes (and plans for more). Seems I'm making a habit of surprising people with new features in my releases, and all I can say is that this next release will be no different. :)
Tuesday, April 13, 2010
1.80 Release
Mostly an optimization release. Changelog since 1.79:
- You can now load maps and then alter them in Mapmaking mode (the map format has been changed so you cannot use maps from older versions)
- Fixed bug preventing maps larger than 64x64 from loading
- Fixed bug with map load button behavior
- Fixed bug with rare crash in Mapmaking mode
- Fixed bug with client-side Merc groups getting the wrong destination
- Several code optimizations for a slight general performance improvement
Wednesday, April 07, 2010
1.79 Release
Changelog since 1.78c:
- MAP CREATION - Choosing a Skirmish game with all Observers will automatically enable Mapmaking mode. It's pretty simple and self-explanatory. We'll see how well it works. Note: you cannot currently load maps as templates and each game you play no longer automatically creates a map file. Also, do not try to load maps made with 1.78!
- BUGFIX - Corrected some crashes with loading maps
- BUGFIX - Fixed bug preventing or causing a crash when trying to restart a network game without exiting program
- BUGFIX - Players will no longer be able to see Pre-Spice Masses if they upgraded in a previous game without exiting program
- BUGFIX - Structures can now correctly be placed on rock in loaded maps
Sunday, March 21, 2010
1.78c Release
(Please re-download this if you downloaded 1.78 or 1.78b earlier today)
Changelog since 1.77:
Changelog since 1.77:
- MAP LOADING - Whenever you start a new game and a map is generated, it will dump a .TGP file to your drive (same folder as the EXE). If you like the map you just played with, keep this file and feel free to rename it (but keep the same extension). You now have an option to load a map inside the chatroom. This is only map data and game settings, not units or player info. Future functionality is planned to include a tool for creating your own maps/scenarios. This feature has been nominally tested
- NEW SOUND FX - Courtesy of TheRaffy we have a new set of cleaned sound fx. The overall size of the packed file has gone up slightly to 2.5mb, but it is well worth it. Some new sounds have also been added to the game
- BUGFIX - Fixed bug with units "stacking" when being produced into enclosed areas
- BUGFIX - Fixed bug with health bar drawing oddly upon unit death
- BUGFIX - Fixed bug with persistent menus for Trading Posts
Sunday, March 14, 2010
1.77 Release
This is a bugfix release (from very successful hunting) that should make network games much more reliable.
Changelog since 1.76:
Changelog since 1.76:
- Increased Infantry units health by 50% and Troopers by 20%. The last update that fixed accuracy issues made foot units start dying at much faster rates. Hopefully this restores a bit of balance
- Total Units listing now also shows total including queues (unfinished units)
- Increased unit turret rotation speed by threefold (turrets should be an advantage after all)
- Fixed bug with client queues not completing properly
- Fixed bug with Sandstorm causing crashes in co-op
- Fixed bug with Palace Alliance causing crashes in co-op
- Fixed bug with demolished buildings not crediting network client
- Fixed bug with auto-concrete failing for network client
- Fixed graphic bug with harvester icon numerator
- Fixed bug with co-op client having all build options despite Tech Level
- More slight network fixes, optimizations and sync improvements
Friday, March 05, 2010
1.76 Release
A jump in versions due more to the volume of code being changed than to the number of updates. Because of the extent of the rewrite, you should probably expect a few bugs to have gotten through.
Changelog since 1.73:
Changelog since 1.73:
- Massive reduction in network bandwidth requirements. You could theoretically even play it on a 56k connection if you kept the unit cap low (not tested though). All network games should be smoother and more stable. I have noticed some slight visual evidence of sync loss at the client side (unit or turret facing might be off sometimes, carryalls don't appear where they actually are, etc), but I don't have evidence yet in all my testing of anything critical going out of sync
- Buildings no longer halt construction when enemy units are close. Instead, the amount of time it takes before you can build on the same spot again after a building is wrecked has been doubled
- Skirmish games now start immediately with no countdown
- Finally fixed the bug with the color-harvesters in the chatroom screen being out of place when exiting and re-entering (wasn't what anyone guessed)
- Fixed bug in network games with construction going too fast
- Fixed bug with concrete placement being too slow in Skirmish mode
- Fixed bug with flags drawing at incorrect speeds
- Added random offset for craters from detonations
Tuesday, March 02, 2010
Network progress
Hey everyone,
I'm making some good progress on a new network sync platform, but I still have some ways to go. I found that some of the current problems are due to the ordering of network messages; it's TCP so they arrive in order, but unfortunately I didn't write my code in the first place to "absorb" network messages in certain locations of operation. Right now there's only one point in each cycle where I catch messages and interpret them, and this is causing some things to get out of sync if say, a message causes a unit to die before it receives its last location update (which can make a bullet miss or a carryall fail to deliver or who knows what). So, it's back to the drawing board on a few fundamental things in the strive for perfection.
On the plus side, next release will have a massive improvement in network performance. I've done a lot of testing and found that the game was requiring enormous bandwidth in some circumstances. Previously I was sending out unit updates on an all-or-nothing basis, where if a unit had any of its stats changed, it sent all of its relevant info in the update. I've since rewritten things so that each unit will track each of its own stats, and will only update those specific stats that change. That part of things is going very well and should lead to a 90-95% reduction in net traffic (yes, you read that right).
Stay tuned in the next couple weeks.
I'm making some good progress on a new network sync platform, but I still have some ways to go. I found that some of the current problems are due to the ordering of network messages; it's TCP so they arrive in order, but unfortunately I didn't write my code in the first place to "absorb" network messages in certain locations of operation. Right now there's only one point in each cycle where I catch messages and interpret them, and this is causing some things to get out of sync if say, a message causes a unit to die before it receives its last location update (which can make a bullet miss or a carryall fail to deliver or who knows what). So, it's back to the drawing board on a few fundamental things in the strive for perfection.
On the plus side, next release will have a massive improvement in network performance. I've done a lot of testing and found that the game was requiring enormous bandwidth in some circumstances. Previously I was sending out unit updates on an all-or-nothing basis, where if a unit had any of its stats changed, it sent all of its relevant info in the update. I've since rewritten things so that each unit will track each of its own stats, and will only update those specific stats that change. That part of things is going very well and should lead to a 90-95% reduction in net traffic (yes, you read that right).
Stay tuned in the next couple weeks.
Subscribe to:
Posts (Atom)