The Ur-Quan Masters Discussion Forum

The Ur-Quan Masters Re-Release => Technical Issues => Topic started by: superbutcherx on November 18, 2009, 09:14:48 am



Title: Creating star system without planets
Post by: superbutcherx on November 18, 2009, 09:14:48 am
Hi again!

The game obviously doesn't like it when I try to force a star system to have no planets or moons at all there. (Crashes when trying to enter such system).
I haven't looked too closely into GENERATE_PLANETS and the function it's calling, but maybe I could change something there to make zero-planet systems work.
Would anyone know what is the particular cause for crash and where in the jungle of code it lies hidden?

Also:
Regarding the same star system tryout: Is it possible to change the star itself into an object one can interact with? I'd like to create a "portal" system of sorts that has absolutely nothing in it except that portal in place of the star and perhaps some Orz ships flying around.(Dang, now I gave that away!)
One way to emulate the effect would be to stick a planet with MIN_PLANET_RADIUS in a super giant system, but it would seem just... half-assed.

Just tell me if I'm bothering you too much with all these questions... It's just that if someone has managed to do this already, it would be kind of waste of time to re-invent the wheel  :)


Title: Re: Creating star system without planets
Post by: meep-eep on November 18, 2009, 01:56:31 pm
In response to your first question, I would suggest that you run the game in a debugger. It should tell you quickly enough where the crash occurs.

As for making the star a portal, that sounds like a fun idea. I have a few ideas of what might be involved, but there are probably other issues which I haven't foreseen. There's a function CheckIntersect in solarsys.c, where the sun is explicitly skipped. The line involved actually has a comment "can't intersect with sun". You will need to remove that check. Then you could add a check to the GENERATE_ORBITAL case of GenerateRandomIP() so that nothing happens when you bump into a sun, unless you override it into a generate function for the specific solar system. But there are a few more issues involved. In ChangeSolarSys, just before the call to GenFunc, there is a call to GetPlanetInfo(). That function isn't able to handle a sun, so you should probably just avoid calling it. It is only relevant for planetary exploration. And after the call to GenFunc, you should make sure that nothing happens for a sun as well.

Be sure to read doc/devel/generate

Also, I happen to be in the process of cleaning up that planet generation stuff (in particular the "overrides" for special planets). You can expect my changes to be checked in into SVN in the next few days.


Title: Re: Creating star system without planets
Post by: superbutcherx on November 20, 2009, 08:32:28 am
Success!  ;D

Thanks yet again for advice! Now Talana literally has a 'place in the sun' at otherwise empty and void Alpha Lyrae...

The empty solar system was easy to make work partially: Just define number of planets for the sun] as 0 at the special star system generation code's GENERATE_PLANETS case. Already this would work otherwise, but if battlegroups were generated inside the system the game would crash.

The problem was in the point in grpinfo.c where all the battlegroups were placed in certain coordinates in the star system. The code would place their coordinates regarding to planets and when there are no planets, it's trouble time.

To correct it, I wrote special cases in grpinfo.c's GetGroupInfo() in couple of places which would work like if (number of planets==0) {place battle groups in about middle of the screen.}

---

Intersecting with the sun worked by changing that "can't intersect with sun" bit of code to work like "can't intersect with sun except if there are 0 planets in the system". To test it I put the syreen conversation code in GENERATE_ORBITAL for Sundesc[0].

At first that crashed, but it seems that when I put GenerateRandomIP for GENERATE_MOONS, GENERATE_ORBITAL and GENERATE_PLANETS and only after the GenerateRandomIP I defined the numplanets=0, the conversation would start upon hitting the sun.

Now the game would crash only when exiting the sun. This was due to DrawOrbit function in solarsys.c. I Changed
pPlanetDesc->image.frame = SetAbsFrameIndex (OrbitalFrame,
               (Size << FACING_SHIFT) + NORMALIZE_FACING (
               ANGLE_TO_FACING (ARCTAN (
               pPlanetDesc->pPrevDesc->location.x,
               pPlanetDesc->pPrevDesc->location.y))));

to

pPlanetDesc->image.frame = SetAbsFrameIndex (OrbitalFrame,
               (Size << FACING_SHIFT) + 2;

in case there were 0 planets in the system so it wouldn't try to read the pPrevDesc's location since I guess there is no pPrevDesc for the sun. This piece of code decides how much zoomed the star should be when drawn on the screen, just a graphical thing.

---

So all in all, it works!
Only thing is that the battlegroups are very insistent on moving from the very center to the left edge of screen to circle some invisible point there. I guess that is because GroupPtr->dest_loc given as a number of planet and when there are no planets...

I Didn't yet try to give -1 as the dest_loc since that just might be the sun (if it works like sortPlanetPositions at solarsys.c) so that's what I need to try next. Oh, and instead of syreens, make it a transition to hyperspace or something better :D

Again, I sounded like a technical manual here... I hope this post will be helpful to some modder out there!


Title: Re: Creating star system without planets
Post by: superbutcherx on November 22, 2009, 02:58:36 am
As for the something better...  :D

(http://img264.imageshack.us/img264/3886/orz.png)

Currently the *Below* a.k.a ORZ space hosts only one portal at 600.0:600.0 that leads back to hyperspace 100.0:100.0 but all kinds of crap can now be thrown in there!

BTW. Is there a better way to modify those colortable files than hex editor and painful labor  :-\ ?


Title: Re: Creating star system without planets
Post by: meep-eep on November 22, 2009, 11:26:03 am
Also, I happen to be in the process of cleaning up that planet generation stuff (in particular the "overrides" for special planets). You can expect my changes to be checked in into SVN in the next few days.
I checked this in yesterday.

BTW. Is there a better way to modify those colortable files than hex editor and painful labor  :-\ ?
No, we never had the need to edit them, afaik.


Title: Re: Creating star system without planets
Post by: fossil on November 27, 2009, 03:23:45 pm
BTW. Is there a better way to modify those colortable files than hex editor and painful labor  :-\ ?
Currently, the tables themselves can only be modified with a hex editor. The palettes contained within the tables are in the same format that PhotoShop uses for it's .act files, except for the first two bytes which specify the starting and ending colormap index. For example, if the starting colormap index is 10 and the ending is 11, then this table entry replaces 2 colormaps in the game and 2 palettes follow the first two colormap index bytes; these palettes are in the .act format: 256 colors, 3 bytes per color, RGB order.

... I should probably just write a doc  ;)


Title: Re: Creating star system without planets
Post by: Death 999 on November 30, 2009, 05:05:30 pm
That's quite a coalition you have going, there, isn't it?


Title: Re: Creating star system without planets
Post by: superbutcherx on December 01, 2009, 12:06:14 pm
Doc would be nice, docs are good! :D

Hmm, so no shortcuts here. Well, it wasn't too hard a thing to do to modify the quasispace green colormap to that Orz space blue, 20 minutes about with a Hex editor.
Things might get hairy though if there was a need to do some more intense stuff like producing graphics for a new race.

But I guess it's just a matter of then doing it in photoshop with a 256 color palette and copying the palette values to a .ct file. Perhaps it is even possible to copy the whole chunk of 256*3 bytes from .act to .ct instead of copying them one-by-one!


Title: Re: Creating star system without planets
Post by: fossil on December 01, 2009, 04:22:30 pm
But I guess it's just a matter of then doing it in photoshop with a 256 color palette and copying the palette values to a .ct file. Perhaps it is even possible to copy the whole chunk of 256*3 bytes from .act to .ct instead of copying them one-by-one!
Certainly, that was the idea. A decent hex editor will let you c&p large chunks of data. However, if I ever undertook a UQM project that required creating new or editing many colormaps, I'd probably first write a tool to disassemble/reassemble colortables. It's not hard to write one at all.

EDIT:
BTW. Is there a better way to modify those colortable files than hex editor and painful labor  :-\ ?
No, we never had the need to edit them, afaik.

Oh, forgot to mention that I did indeed have to edit the colormaps, but the edits were not very large, so I did that by hand.


Title: Re: Creating star system without planets
Post by: Quinarbre on December 03, 2009, 12:11:24 pm
It seems one such tool has been written for Project6014 :

http://code.google.com/p/project6014/source/browse/#svn/trunk/tools/ctconv

It converts from CT to RGB. I don't know if the reverse tool is available but that should at least ease your work a bit.


Title: Re: Creating star system without planets
Post by: fossil on December 03, 2009, 06:15:08 pm
Ah, that one... It wasn't written for Project6014. I wrote that ctconv for UQM to expand 3DO CLUTs to full 256-color palettes in the colortables. ;)  3DO used a colormap system different from what we are using now. The CLUTs were 32 colors each (instead of 256), 5 bits per channel (15 total), with an implied 3-bit luminosity value. So 32 x 8 = 256, the expanded count. The CLUT system was thusly limited, and there was substantial color loss from DOS originals in some parts of the game.
But yeah, I had forgotten about this tool. At the very least, it handles the colortable format already and can be adapted to disassemble/reassemble colortables for editing.


Title: Re: Creating star system without planets
Post by: meep-eep on December 03, 2009, 06:39:11 pm
This tool can also be found in the Subversion repository for UQM. I guess that would be the "official" location.


Title: Re: Creating star system without planets
Post by: Quinarbre on December 04, 2009, 12:43:52 am
My mistake, I must admit I'm not familiar with the various repositories here and there.


Title: Re: Creating star system without planets
Post by: superbutcherx on December 05, 2009, 01:31:55 pm
Hmm, interesting!

The ctconv was already there in the tools of my current subversion so I can use it as a starting point if I want to create a tool for changing the colortables.

Currently I've been fiddling about with the hyperspace stars and spoor graphics. Planting the normal hyperspace graphics into the Orzspace leaves and ugly red glow around the graphics. A most efficient way of eliminating this would of course to define in something like orzspace.ani that the graphics in orz space use a different color table.

This color table is specified by a number after the .png file name and its transparency color index in the .ani file.

Where in the .ct files it is defined which number it is? For example, hyperstars. ani specifies the graphics to use colortable number 54.

Also, when editing the .png files with photoshop, the 4 kB files always bloat into 50kB+ files after saving. I specified that PS doesn't add color profile (the original game gfx don't use these) but even that only lowered the filesizes from 57kB to 53kB.
This isn't major issue, but I like to optimize things, a nerdy idiot that I am.


Title: Re: Creating star system without planets
Post by: meep-eep on December 05, 2009, 03:24:03 pm
Where in the .ct files it is defined which number it is? For example, hyperstars. ani specifies the graphics to use colortable number 54.
See /doc/devel/strtab in the UQM source tree.

Quote
Also, when editing the .png files with photoshop, the 4 kB files always bloat into 50kB+ files after saving. I specified that PS doesn't add color profile (the original game gfx don't use these) but even that only lowered the filesizes from 57kB to 53kB.
You can use the tool svg (http://www.catb.org/~esr/sng/) to find out what the bloat consists of. If you can't tell PhotoShop not to include that data, you could use GIMP (http://www.gimp.org/) to modify your images instead.


Title: Re: Creating star system without planets
Post by: fossil on December 06, 2009, 08:39:23 pm
Planting the normal hyperspace graphics into the Orzspace leaves and ugly red glow around the graphics. A most efficient way of eliminating this would of course to define in something like orzspace.ani that the graphics in orz space use a different color table.
...
Where in the .ct files it is defined which number it is?

Actually, you do not need to create an orzspace.ani. Instead, you can just create a new palette for hyperstars.ani to use, a palette that carefully replaces those Hyperspace red hues with whichever hues your Orzspace uses (blue?). You can put this palette into your orzspace.ct. This is best demonstrated with this actual example (but do read the doc meep-eep mentioned and also see my post above about the starting and ending colormap index). It can be confusing: colortable vs. colormap, but we do not have better names for them. A colormap is a 256-color palette, and a colortable is a file containing colormaps.

So on to the example:
* ambient.ani uses colormap 53
* hyperstars.ani uses colormap 54
* hyperspace.ct defines colormap 53, but not 54, because hyperstars.ani is only ever used in Hyperspace (Quasispace uses quasispace.ani instead). IIRC, colormap 54 is defined by base/uqm.ct, which also defines most colormaps used in the game, especially the ones that never change.
* quasispace.ct also defines colormap 53, but you already know that because you made your own orzspace.ct
* the assumption is that you want to use hyperstars.ani in Orzspace and not create a brand new one

How do I know they define colormap 53? Open one of these .ct files in a hex editor and follow the layout with doc/devel/strtab. At offset 0x10 you will find the beginning of the first (and only, in this case) colortable entry. The first two bytes of this entry are the starting and ending colormap indices, which are both 0x35 (or 53 in decimal). What follows is the colormap, 256 * 3 = 768 bytes. Note the size of this entry at offset 0x0c: it is 0x00000302, or 770 in decimal = 2 + 768.

So what you may want to do is make your orzspace.ct define both colormaps 53 and 54. In that case, you leave the starting colormap index 53, make the ending index 54, insert the new colormap 54 at the end of the entry (or in this case, append to the end of the file), and change the size of the entry to account for an added colormap (2 + 768 + 768).
When this new orzspace.ct is loaded and activated with SetColorMap(), it will replace colormaps 53 and 54, and your hyperstars will be drawn using the palette you defined. While the legacy name does not suggest so, SetColorMap() can replace more than one colormap.

There is just one catch.  ;D  Once you load and set orzspace.ct, colormap 54 will be forever replaced in the game. So when you go back to Hyperspace, the stars will have an ugly blue glow around them :P This will happen because, of course, hyperspace.ct does not define colormap 54, but you already know how to fix that. You will just have to fish colomap 54 out of base/uqm.ct.
EDIT: You could also simply save the palette from hyperstars-000.png into an .act file, and that will become colormap 54 for hyperspace.ct. But I do not guarantee that the PNG palette is exactly the same as colormap 54 in uqm.ct. Most of the PNG palettes in UQM graphics are there just so a human could see what a graphic is. Such palettes are not used in the game, and instead the colormaps define the colors, as you probably realized already.

Also, when editing the .png files with photoshop, the 4 kB files always bloat into 50kB+ files after saving.
Make sure that PS does not convert these PNGs to 24-bit color. Some versions of GIMP, for example, are known to clobber the palette, rearrange it randomly, etc., and that can make these PNGs unusable by UQM.


Title: Re: Creating star system without planets
Post by: superbutcherx on December 09, 2009, 08:41:42 am
Thanks for the comprehensive example and SW tips, you guys are full of good advice!

So far I've used a separate orzspace.ani since I've got some new graphics in the orz space in addition to some of the hyperspace gfx. The way I've done the colors for them is to simply switch off the colormap specifying number in the .ani file, forcing the PNG's own palette to be used.
This is OK for single frames, but with animations of multiple frames I think I'll go for the way you described in the example.

My ultimate dream is to make a real sequel out of this thing eventually, but then again, that might never happen... So as the first step I'm taking the route someone (Angelfish?) suggested in another topic: Make it a small add-on for the original UQM. This shouldn't take too long and it would also let you guys see what I've been able to accomplish!