Messages

61

Discussion / Re: Production for profit

« on: June 14, 2010, 01:11:01 am »

If you have a highly customizable, easily retooled facility that you can configure to produce whatever, there is a downside: It's absolutely going to only be able to produce small unit volume, which is going to drive the manufacturing cost per unit through the roof, because the facility itself and the workers there represent significant fixed costs.

The Phalanx manufacturing facilities are precisely of this type.

OK, fine. Very high costs.

Still, since we are the only supplier of these things, we can set the price. Might not get a buyer, but there's no reason to set the price low.

===
If we are unable to sell at a higher price, because someone else is making stuff and selling at that price, why can't we buy from them?

If we can't buy at that price, no one else can buy at that price. So, raise the price we sell at.

62

Discussion / Re: Production for profit

« on: June 13, 2010, 04:28:29 am »

No, you can't produce anything and sell it for a profit.

Alright, what can you produce and sell for more than the cost of the materials, to cover the most of your fixed expenses?

Are the engineers you need to hire, and the workspaces you use, really so expensive that the items produced are just not wanted at that price by anyone? I mean, it's literally technology that's out of this world. No one on this planet has weapons like yours. Gotta be some would-be dictator elected president that wants it, right?

As the seller, you should be able to say "this is what I'll sell for". Maybe the purchase rate won't be very high at that price. I know the normal view is "An infinite number can be sold at this price", but maybe a more complex model would allow a few per month at a higher rate (kinda like how you can recruit a few soldiers per month, etc.).

63

FAQ / Re: GLSL shaders NOT available -- what happens?

« on: June 13, 2010, 03:28:14 am »

Done -- 3015331

64

FAQ / Re: GLSL shaders NOT available -- what happens?

« on: June 07, 2010, 07:06:37 am »

Bump

What is done by the GLSL shaders when they are available, and where is that action triggered?
What fallback path happens when they are not?

Is there an "if (glsl_shaders) {foo} else {bar}" point?

As I said, I've got one PPC machine with GLSL support, and it displays fine, but at 25 seconds per frame is unplayable. We know that the PPC compiled maps work fine on i386, so it's probably not the map editor or the map compiler (yet i386 compiled maps are so much worse on the PPC); we know that i386 with GLSL turned off looks good, so that leaves something about PPC software light generation.

I am out of my league here; I don't know what to look for, or what values are reasonable. Can someone who knows this please add some debugging output to the code so this can be identified? Thank you.

65

Mac / Re: Current issues with 2.3 PPC build (Now with Graphics!)

« on: May 31, 2010, 07:30:06 pm »

that sounds like there is an endian issue in loading or saving the lightmap data - because they are calculated on a little endian system

Ok, where in ufo is the lightmap data read in, and what values should be seen? Do the lightmap values change as you rotate the map? (What's displayed does change as the map is rotated, and sometimes on a per-frame toggle.)

Lets see if we can get some debugging patches, and then see what values are read/used on ppc/x86.

Oh yea -- Local compiled farm maps are "mostly good" with minor issues, and the rare, occasional good.

66

Discussion / Re: Fuel Pods are they worth it?

« on: May 31, 2010, 07:23:21 pm »

and in the initial build screen, all buildings you build are instantly complete

THAT sounds like something that should be emphasized. I thought "Don't start with buildings" was a way to make the game much harder -- you start with just an entrance and have to build everything over time.

67

FAQ / Re: Is this what a map is supposed to look like?

« on: May 30, 2010, 03:24:55 am »

So then it's definately UFO. It's not a case of radiant writing something wrong to the .map, nor is it ufo2map putting bad stuff in the .bsp. It's in UFO somewhere.

Good; that's half the potential trouble spots eliminated.
===

Why then are x86 compiled maps so much worse than local maps?

Need to test GLSL shader and x86 compiled maps...

68

FAQ / Re: Is this what a map is supposed to look like?

« on: May 29, 2010, 04:24:14 am »

Here's my compiled dam.bsp. Let me know what it looks like on your system.

69

Mac / Re: Current issues with 2.3 PPC build (Now with Graphics!)

« on: May 29, 2010, 01:23:57 am »

... and 4 more loads of farm all gave the "spectacular failure" that I'm used to.

Compiling all the farm tiles locally now...

70

Mac / Re: Current issues with 2.3 PPC build (Now with Graphics!)

« on: May 28, 2010, 09:36:29 pm »

Which is what I thought, and was hoping to find.

But as I said, I got a perfect load on "Farm" (downloaded). Other than it looks like completely flat ground, I didn't see anything else different from the other maps.

71

FAQ / Is this what a map is supposed to look like?

« on: May 28, 2010, 08:22:24 am »

Is this what the "dam" map is supposed to look like?

72

Mac / Re: Current issues with 2.3 PPC build (Now with Graphics!)

« on: May 28, 2010, 08:03:17 am »

NAARG.

I thought I had tracked down the spectacular failure case to being the downloaded maps. But "farm" displays perfectly with the downloaded map.

Sigh. The downloadeds seem to be worse, but not guaranteed bad.

73

FAQ / What happens when a map has more light sources than the hardware?

« on: May 27, 2010, 07:47:36 am »

What happens if there are 9 direct lights ("wilderness.bsp") and the hardware supports 8 lights?

Is the behavior consistent -- should the program do the same thing (drop the weakest light, I'd assume) in each case?

Can this be sufficient to explain the lack of proper lighting when GLSL shaders are turned off, yet still give proper lighting with them turned on?

And what effect, if any, would the realtime lighting setting have in that case?

74

FAQ / Re: GLSL shaders NOT available -- what happens?

« on: May 27, 2010, 05:24:30 am »

Ok, a little farther:

Code: [Select]

131 * @brief Use the vertex, texture and normal arrays to draw a surface
132 * @sa R_DrawSurfaces
133 */
134 static inline void R_DrawSurface (const mBspSurface_t *surf)
135 {
136 debug(0);
137 glDrawArrays(GL_POLYGON, surf->index, surf->numedges);
138
139 if (r_showbox->integer == 2)
140 R_DrawBoundingBox(surf->mins, surf->maxs);
(gdb) p surf->index
$7 = 18763
(gdb) p surf->numedges
$8 = 4
(gdb) p surf
$9 = (const mBspSurface_t *) 0x2e552c8c
(gdb) p *$
$10 = {
  plane = 0x2d5c102c,
  flags = 2,
  tile = 0,
  frame = 2,
  firstedge = 18763,
  numedges = 4,
  stmins = {4992, -2688},
  stmaxs = {6080, -2304},
  stcenter = {5536, -2496},
  stextents = {1088, 384},
  mins = {1486.40002, 768, 6},
  maxs = {1788.80005, 856, 6},
  center = {1637.6001, 812, 6},
  color = {0, 0, 0, 1},
  normal = {0, 0, 1},
  light_s = 1941,
  light_t = 14,
  lightmap_scale = 64,
  index = 18763,
  tracenum = 0,
  texinfo = 0x2b15d02c,
  flare = 0x0,
  lightmap_texnum = 1024,
  deluxemap_texnum = 1280,
  samples = 0x2d5a7d4b "BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BB"...,
  lightmap = 0x2b06ea6c '?' <repeats 200 times>...,
  lightframe = 0,
  lights = 0,
  isOriginBrushModel = qfalse
}
glDrawArrays looks interesting. It is being given a type (polygon), an index, and number of corners (4; so much for my thought that everything was triangles), but it isn't given a list of verticies, only index and count.

"Samples" and "lightmap": Are those values reasonable? Should they be initialized by this point?

75

FAQ / Re: GLSL shaders NOT available -- what happens?

« on: May 27, 2010, 05:05:54 am »

Alright, is this reasonable?

Code: [Select]

(gdb) list
60 static void R_ModLoadLighting (const lump_t *l, qboolean day)
61 {
62 r_worldmodel->bsp.lightdata = Mem_PoolAlloc(l->filelen, vid_lightPool, 0);
63 r_worldmodel->bsp.lightquant = *(const byte *) (mod_base + l->fileofs);
64 memcpy(r_worldmodel->bsp.lightdata, mod_base + l->fileofs, l->filelen);
65 debug(r_worldmodel->bsp.lightdata);
66 }
67
68 static void R_ModLoadVertexes (const lump_t *l)
69 {
(gdb) p l->fileofs
$2 = 1426600
(gdb) p l->filelen
$3 = 286387
(gdb) p r_worldmodel->bsp.lightdata
$4 = (byte *) 0x2d57202c "\006BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?BBB?????BBB?^^L~?BBB?BBB~?CCB~?BBB?BBB?BBB?BBB?BBB?BBB?DDC~?JJE~???~~?BBB?BBB?BBB?BBB?BBB?BBB?BBB?????BBB?B"...
(gdb)
I'm loading the wilderness map. If I'm reading this correctly, then memcpy has just copies 286,000 bytes for the lightmap data. Is that a reasonable size for light information? Does that look like valid lighting information?

What really makes this odd: I'm still getting the occasional "perfect" load, and about 75-90% odd shadow. That spectacular failure isn't repeating.

(debug() is just a convenient place to put a gdb breakpoint)

===
What is done by the GLSL shaders when they are available, and where is that action triggered?
What fallback path happens when they are not?

Is there an "if (glsl_shaders) {foo} else {bar}" point?