Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Patching extra functionality into <gamemd.exe>
Yes. I planned it for 1.09Smile
Now I write utility which allow to convert PNG, BMP, JPG files into SHP16.
ARM forever - x86 sucks!


CnCVK Wrote:Now I write utility which allow to convert PNG, BMP, JPG files into SHP16.
don't forget PCX
us XCC users keep everything in PNG or for the older version PCX. and the older versions are better, because the newest 1 crashes when you try to do anything with PNG at all.
I'm currently rewriting the whole SW loading routines.
so @CnCVK: don't mess with superweapons now, please!

BTW, you said instead of using temp values, I should use temp superweapons.
that's a good idea.
I'll put 8 temp superweapons into the game, so you can have 8 cloned superweapons active at a time (atm, you can only have one, did anybody notice that? well, it could cause IEs I think)

EDIT:
hm, some things have to be stored in temp variables, but I'll keep them as little as possible Smile
[Image: jsfml.png]
Quote:don't forget PCX
256-colors PCX files into SHP-65536 colors.. funny
Also I forgot BMP Smile
Quote:BTW, you said instead of using temp values, I should use temp superweapons.
that's a good idea.
I talk about pointers to SuperWeaponTypeClass.
Quote:I'll put 8 temp superweapons into the game, so you can have 8 cloned superweapons active at a time (atm, you can only have one, did anybody notice that? well, it could cause IEs I think)
And how you check which LStorm now need process?

@PD about save bug:
00BA16CFh Old = 74h New = 0EBh  
I assumed that information in YRClasses 2 is rightMad
line from "YRClasses 2":
0x20C AnimType* NukeFirstAnim
but you stored LPSTRUnhappy
ARM forever - x86 sucks!


On the topic of the electricbolts, any way to get them transparent so you would only be able to see one or two and not the full three? perhaps a special case for the tag like;

EBoltColor1=transparent
[Image: sig.jpg]
For the electrobolt colours, would it be difficult to do something like this:

EBoltColor1=0,house,0
EBoltColor2=house,house,house
EBoltColor3=house+100,transparent,house-100

or is that too difficult/inefficient?
[Image: Sig.jpg]
[Image: awesomeballs.gif]
i think we should introduce special numbers for this, like for the verses.

a color value of 1,1,1 could mean transparent,
2,2,2 could mean housecolor

since there's almost no difference between 2,2,2 and 0,0,0, that shouldn't be a problem and wouldn't need to many special routines.
thoughts?

"CnCVK Wrote:I assumed that information in YRClasses 2 is rightMad
line from "YRClasses 2":
0x20C AnimType* NukeFirstAnim
but you stored LPSTRUnhappy

I noticed this today when I rewrote the SW loading routines...
sorry, I thought it would be an AnimType (jonwil coded the nuke clones, I didn't know Unhappy )
but K, i'll fix it.
i will have the new sw loadings finished soon.
besides I play a BIG update on the anim SW Wink
[Image: jsfml.png]
Kushan Wrote:For the electrobolt colours, would it be difficult to do something like this:

EBoltColor1=0,house,0
EBoltColor2=house,house,house
EBoltColor3=house+100,transparent,house-100

or is that too difficult/inefficient?

Uh, rgb doesn't work like that, what you have suggested would probably cause numerous crashes.
The values are specified as RGB so the first value is how much red there is, second is green and third blue. Like mixing paint together you can have any colour you like from using different amounts.
Specifiying something like;

EBoltColor3=100,100,0

would mean 100 red, 100 green and 0 blue. You would get a yellow colour. Something like;

EBoltColor3=house+100,transparent,house-100

would mean that the first value (red) would be your house colour plus 100 red. But, if your house colour is green that makes it green + 100 red.
green + red doesn't make red it makes yellow and im not sure how the game would handle this.

@Pd: I think that is a very good idea but i still think having a single term for the two variations would be much easier (modder wise, i have no idea if it would be easier for you) and avoid such confusion as above. i.e.

EBoltColor2=transparent
EBoltColor3=house
[Image: sig.jpg]
CnCVK Wrote:
Quote:don't forget PCX
256-colors PCX files into SHP-65536 colors.. funny
PCX files can be 24 bit.
Tratos Wrote:
Kushan Wrote:For the electrobolt colours, would it be difficult to do something like this:

EBoltColor1=0,house,0
EBoltColor2=house,house,house
EBoltColor3=house+100,transparent,house-100

or is that too difficult/inefficient?

Uh, rgb doesn't work like that, what you have suggested would probably cause numerous crashes.
The values are specified as RGB so the first value is how much red there is, second is green and third blue. Like mixing paint together you can have any colour you like from using different amounts.
Specifiying something like;

EBoltColor3=100,100,0

would mean 100 red, 100 green and 0 blue. You would get a yellow colour. Something like;

EBoltColor3=house+100,transparent,house-100

would mean that the first value (red) would be your house colour plus 100 red. But, if your house colour is green that makes it green + 100 red.
green + red doesn't make red it makes yellow and im not sure how the game would handle this.

@Pd: I think that is a very good idea but i still think having a single term for the two variations would be much easier (modder wise, i have no idea if it would be easier for you) and avoid such confusion as above. i.e.

EBoltColor2=transparent
EBoltColor3=house

I know how RGB works, the idea behind it was so that modders could specify just how much variation there was between house colours used. I was thinking the value "house" would just pick the value of the R, G or B from the house colour and the other value would add to it by the amount specified up to 255..

From what PD said though, I think he's on to something. You could maybe even have 3,3,3 as "house colour + random offset" for a bit of variation.
[Image: Sig.jpg]
[Image: awesomeballs.gif]
Quote:PCX files can be 24 bit.
But 24-bit PNG better then PCX, and I have not any documentation about 24-bit PCX.
However, my program is supporting only BMP files.
Another files, such as JPG, GIF, PNG, are using "Image Filter". Smile
ARM forever - x86 sucks!


The single term method seems best, but one additional term could be added if it is house color. This would be a greyscale indicator so that the game knows how dark or light to draw the house color.

For example:
EBoltColor2=transparent
EBoltColor3=house,50

I have no idea what units to use for that; the number 50 was completely arbirary. But you get my idea?
[Image: alexstand1.gif]
of course I get the idea, and I'll overthink this again (got a note in my TODO list Tongue )

so I decided to release a 1.08b version, it will not include many new features, but at least a few (mostly SW related).
of course, the main attention is on bugfixing.

something I noticed is that despite my thoughts a few people don't know about RAR, that's why in the future, I'll not compress the installer anymore (it's compressed 20KB or so only, so that's no problem to anybody).
[Image: jsfml.png]
Quote:EBoltColor2=transparent
EBoltColor3=house,50
However we have another, more impotant thingsSmile
ARM forever - x86 sucks!


Of course. I will never even USE this feature if it is implemented. I was just sharing ideas.
[Image: alexstand1.gif]




Users browsing this thread: 1 Guest(s)