User:Renegrade - Revision history

Renegrade: /* Enemy Unknown */

2010-08-19T14:23:38Z

Enemy Unknown

← Older revision		Revision as of 14:23, 19 August 2010
Line 24:		Line 24:
	* Clean up code.		* Clean up code.
	* Make some art~		* Make some art~
			* Writing out and compressing BDYs

	Done:		Done:
Line 31:		Line 32:
	* Compressing SPKs		* Compressing SPKs
	* Merge sub-programs		* Merge sub-programs
			* Decompress BDYs

	I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.		I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

Renegrade: /* Random Z-Com thoughts */

2010-08-10T11:19:36Z

Random Z-Com thoughts

← Older revision		Revision as of 11:19, 10 August 2010
Line 111:		Line 111:
	# Show it as non-summed items. Ex: Rifle Clip 14 (20) --> 14 rifle clips at the base, 20 en route via transfers from purchasing or other bases.		# Show it as non-summed items. Ex: Rifle Clip 14 (20) --> 14 rifle clips at the base, 20 en route via transfers from purchasing or other bases.
	# Show it as summed items. Ex: Rifle Clip 14 (34) --> 14 rifle clips at the base, with 20 enroute = a total of 34. I tend to favor this approach as it eliminates the possibility of faults with mental math.		# Show it as summed items. Ex: Rifle Clip 14 (34) --> 14 rifle clips at the base, with 20 enroute = a total of 34. I tend to favor this approach as it eliminates the possibility of faults with mental math.

			* Fix the manufacturing bug. I actually have a hard time imagining the code that causes it, yet still allows proper rollover of hours. If something takes 5 engineering hours, and there's 12 engineers working on it, it should produce ''two'' on the hour, and save 2 engineer hours for the next '''anything''' (including new projects), with an ideal design.

			* Also, the manufacturing page suggests that resources are gathered too quickly and/or not returned properly when cancelling. The best design for that would be that every time a new item in a batch is initiated, the cash and items required are extracted from the base stock, but then 'stored' in the manufacturing data. If that item is cancelled, then that stored cash/item list can be restored to the base's main stock.

Renegrade: /* Random Z-Com thoughts */

2010-08-10T11:13:44Z

Random Z-Com thoughts

← Older revision		Revision as of 11:13, 10 August 2010
Line 101:		Line 101:

	==== Random Z-Com thoughts ====		==== Random Z-Com thoughts ====

			(things to consider implementing in Z-Com)

	* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:		* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
	# prohibit access to the inventory entirely. Skip over it when toggling through troops.		# prohibit access to the inventory entirely. Skip over it when toggling through troops.
	# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc		# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

			* Show the current AND expected stock in the Buy screen; ie, including transfers 'in flight' to that base. Could work one of two ways:
			# Show it as non-summed items. Ex: Rifle Clip 14 (20) --> 14 rifle clips at the base, 20 en route via transfers from purchasing or other bases.
			# Show it as summed items. Ex: Rifle Clip 14 (34) --> 14 rifle clips at the base, with 20 enroute = a total of 34. I tend to favor this approach as it eliminates the possibility of faults with mental math.

Renegrade: /* Enemy Unknown */

2010-08-06T09:25:21Z

Enemy Unknown

← Older revision		Revision as of 09:25, 6 August 2010
Line 22:		Line 22:
	To do:		To do:
	* Improve Color Indexing algorithm.		* Improve Color Indexing algorithm.
	* Clean up code~~, merge sub-programs~~		* Clean up code.
	* Make some art~		* Make some art~

Line 30:		Line 30:
	* Writing out Uncompressed SPK		* Writing out Uncompressed SPK
	* Compressing SPKs		* Compressing SPKs
			* Merge sub-programs

	I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.		I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

Renegrade: /* Enemy Unknown */

2010-08-05T07:54:47Z

Enemy Unknown

← Older revision		Revision as of 07:54, 5 August 2010
Line 26:		Line 26:

	Done:		Done:
	* Reading BMPs		* Reading BMPs (this has been improved somewhat)
	* Color Indexing (may need improvement)		* Color Indexing (may need improvement)
	* Writing out Uncompressed SPK		* Writing out Uncompressed SPK

Renegrade: /* Various Utilities */

2010-08-04T09:15:11Z

Various Utilities

← Older revision		Revision as of 09:15, 4 August 2010
Line 9:		Line 9:
	=== dirt.exe ===		=== dirt.exe ===

	dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It ~~does~~ the ~~same thing~~, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.		dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It fixes the 'paying for dirt' bug, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

	<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>		<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>
Line 18:		Line 18:
	==== Enemy Unknown ====		==== Enemy Unknown ====

	I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file. ~~(Current progress~~: ~~reading~~ BMPs~~, color indexing, and writing~~ out ~~an SPK format file is done. Todo: compress the~~ SPK ~~with RLE)~~		I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file.

			To do:
			* Improve Color Indexing algorithm.
			* Clean up code, merge sub-programs
			* Make some art~

			Done:
			* Reading BMPs
			* Color Indexing (may need improvement)
			* Writing out Uncompressed SPK
			* Compressing SPKs

	I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.		I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.
Line 30:		Line 41:
	I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.		I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

			=== NameStat ===

			It's a little program like the StatString one. This one ranks the agents based on a scaling grade in terms of reaction and aiming, and optionally gives psi ability data. Agents are ranked from 0-9 (with a special 'E' symbol for ones who Exceed the caps), with 0 meaning someone with the lowest possible recruit score, and 9/E being a maximum-skill agent.

			=== UnitScan ===

			A little cheat program to scan a battlescape save to show what's going on. I use it to find that last alien or two who's hiding in some obscure corner of the map. Especially useful for TFTD and it's complicated maps.

	=== Mission Item Recovery Enhancement ===		=== Mission Item Recovery Enhancement ===

Renegrade: /* Z-Com */

2010-08-04T05:26:48Z

Z-Com

← Older revision		Revision as of 05:26, 4 August 2010
Line 80:		Line 80:

	Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.		Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

			==== Random Z-Com thoughts ====

			* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
			# prohibit access to the inventory entirely. Skip over it when toggling through troops.
			# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

Renegrade at 05:23, 4 August 2010

2010-08-04T05:23:24Z

← Older revision		Revision as of 05:23, 4 August 2010
Line 1:		Line 1:
	Just an old DOS/Amiga programmer who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.		Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.



			== Various Utilities ==

			I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

			=== dirt.exe ===

			dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It does the same thing, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

			<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>


			=== Paperdoll Improvement Project ===

			==== Enemy Unknown ====

			I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file. (Current progress: reading BMPs, color indexing, and writing out an SPK format file is done. Todo: compress the SPK with RLE)

			I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

			I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

			The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

			==== TFTD ====

			I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.


			=== Mission Item Recovery Enhancement ===

			The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

			Example 1:
			* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
			** 8 of them fire 1 shot (8 bullets)
			** 4 of them fire 2 shots (8 more bullets)

			That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

			Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.


			Example 2:
			* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
			** 5 of them fire 2 shots (10 bullets)
			** 3 of them fire 5 shots (15 more)
			** 2 of them fire 12 shots (24 more)
			** 1 of them empties an entire clip (20 more)

			Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

			A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

			The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

			=== Z-Com ===

			One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

			* 3D accelerated engine (no more lag on the upper levels of Battleships!)
			* Enhanced art, but with the same ''style'' as the original
			* Higher resolution graphics (less jaggies!)
			* Better stores/soldiers/ammo management capabilities
			* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

			Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

			If it did happen though, it would likely happen in stages:

			# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
			# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
			# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
			# Implementation of user-created graphics sets

			The final version would run entirely on it's own without any original XCOM data.

			Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

Renegrade: New page: Just an old DOS/Amiga programmer who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A00...

2010-02-02T14:50:40Z

New page: Just an old DOS/Amiga programmer who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A00...

New page

Just an old DOS/Amiga programmer who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.