Messages

1741

Programming / Re: Let there be light

« on: July 09, 2010, 06:23:58 pm »

https://www.pmprog.co.uk/tmp/xcomlight.swf

Code is in VB.NET for now (just checking my maths); Will convert to C++ later

I couldn't make much sense of the code, but the result looks alright. If you're making a light calculation based on time, something you should remember:
- Even though X-Com longitude goes from 0..360 (as opposed to -180..180), the GMT line is still at 0 longitude.
- Therefore, the "daylight" is centered at 0 at 12:00GMT, and the "nightlight" is centered at 0 at 0:00GMT (24-hour-format).

Edit: SupSuper, if you think I'm "helping out" too much, let me know. I don't want you to feel like I'm railroading your project 

It's fine. As long as you keep working on the things I really don't feel like working on and would postpone for weeks (UGH GLOBES MATHS TRIGNOMETRIES THAT CAN WAIT), things get done faster.

1742

Suggestions / Re: Configurable alien/civilian counts for terror missions or base assaults?

« on: July 09, 2010, 06:05:01 pm »

Have you been reading GuavaMoment's Lets Play UFO too?   
https://lparchive.org/LetsPlay/XCOMUFODefense/

Haha those are some good ones, I even embarrassed myself horribly participated in his TFTD LP.

1743

Programming / Re: Textures

« on: July 08, 2010, 11:20:15 pm »

Ok it's all in the SVN now so there should be no more confusions.

1744

Programming / Re: small fix

« on: July 08, 2010, 11:17:17 pm »

Fixed.

Visual Studio didn't mind so I missed it.

1745

Programming / Re: Newlines

« on: July 08, 2010, 11:16:59 pm »

Added.

Funny how every compiler has their own nitpicks.

1746

Programming / Re: Textures

« on: July 08, 2010, 10:06:28 pm »

I'm sorry you still went to the trouble, but I said in my post that I had already took care of the marker slowdown and that wasn't what was slowing down textures. It's been with me from the beginning.

Edit:

Here you go... All working.

The bottleneck was on SDL_SetColorKey() in your Surface constructor. I removed the SDL_RLEACCEL flag, and bingo...

Oh hey, thanks for that. Funny how things that are supposed to accelerate always end up backfiring.

1747

Open Feedback / Re: GitHub ?

« on: July 08, 2010, 05:55:52 pm »

I've been reading up and from what I can tell SVN uses a central repository while Git is distributed among users and it's kinda faster and stuffs.

I can see the appeal but I really like TortoiseSVN and Git doesn't seem to have a Windows equivalent, plus this is mostly a one-man ship so a central repository is fine, so for now I'm sticking with SVN. If Git becomes more user-friendly and better integrated later on I might switch, since Sourceforge seems to already support it.

1748

Programming / Re: Textures

« on: July 08, 2010, 01:34:35 am »

Hmmm, interesting that theirs runs fine. Tell me, do you redraw the globe every frame?

Potentially, what you could do to speed things up, is buffering the globe post-world, but pre-objects (such as bases, UFOs and other craft). This way, when a draw request is done, then you simply blit that across, then overlay the objects.

Then, when the world is rotated, you update the buffered surface, again without objects. This means you're not having to calculate and recalculate and render 20+ textured polygons each frame, cutting down to a single blit.

After all, there's no point in recalcing everything if the view is exactly the same

This is already how it worked (you can see for yourself if you comment out all the base markers stuff or just go back a few revisions), I just wanted to see the base placement in action so I didn't bother to optimize it and place the base markers in a separate surface, I'll do it eventually.

As a general rule, the draw() function in objects takes care of redrawing the buffered surface whenever a relevant property changes. While the blit() function takes care of rendering the buffered surface onto the screen (this is what happens every frame). So everything is blitted every frame onto the screen (as it should or you'd get horrible tearing effects) but everything isn't "redrawn" every frame (like, say, a button only redraws itself when it's pressed/released). It's kinda ambiguous naming because I'm not good with names.

It still doesn't solve the problem that merely attempting to move the globe will still bring the game to a near-halt (which, again, doesn't happen with X-Com Reloaded). Hell, even a DOS game could do it, it's kinda embarrassing.

1749

Programming / Re: Textures

« on: July 08, 2010, 12:11:17 am »

Thanks, your solution was the same one I had in mind, I just never got around to it. I'll have a look later and add it in.

For future reference, I'd appreciate it if you posted code changes as patch files instead, as they're much easier to manage. I even created a topic about it to feel all important.

As for the texturedPolygon() routine, I did consider rewriting it to use pixel-level drawing instead of blits (as they seem to be much slower), but then I found out my evil twin the other X-Com remake seems to use the exact same method for drawing their globe, only theirs actually works fast! I've pretty much compared the code line by line and can't really figure out what am I doing wrong compared to theirs.

1750

Programming / Compiling on Cygwin

« on: July 07, 2010, 09:18:43 pm »

Glad you got it working, I'll remember to fix the makefile. Funny how the weirdest things can cause problems. You probably also needed the SDL DLLs to run the game since you're building for Windows.

As for the DATA thing, I will admit that the error handling at this point is vague to nearly non-existant, it's not really a priority, but you should at least see an error message if the game fails to load (or at least I do):


Yes it's not very descriptive or very flashy, but it does the job, and I would expect people to be able to read a few instructions. The current builds aren't intended for the average user after all. Of course I have no idea what'll happen if your computer decides to not show the console. The message might jump into an abyss. The program might just crash. Who knows.

But I can't use anything platform-specific like MessageBox() either. I'd have to render a message myself onto the SDL screen. Problem is, if the game fails to load the resources, there aren't even any palettes or fonts to draw a message! I'd need some kind of failsafe resources to manage to scribble a desperate cry for help on the screen. Again, another thing for the TODO list.

1751

Suggestions / Re: Starting Base

« on: July 07, 2010, 01:47:42 am »

It would be interesting to be able to customize your starting base, though you would probably need a "set-up month" so your funding doesn't plummet as well, or a special setting so funding and time are frozen until you're done. At least it would let you play around with various setups.

Although in the long-run players probably just have one favorite layout and would be happy just customizing the game files to always get it when they started the game.

1752

Programming / Re: Let there be light

« on: July 07, 2010, 01:38:22 am »

Well the real globe has actual textures (I haven't applied them because they cause terrible performance for some mysterious reason)

Yeah, totally forgot about them. In fact, I've been having a bit of a look at textures tonight, I can't seem to render them. They either don't draw anything, or crashes in the Surface::getPixel with _surface->pixels = 0x00000000. Odd.

Enabling the poor texture rendering is an exercise in horror and shock and possibly frustration, but here goes:

1. Go to the Globe::draw function in Globe.cpp.
2. Comment out the filledPolygonColor(...) line and uncomment the texturedPolygon(...) line.
(if you're having fun you can also uncomment the polygonColor(...) line instead and see the globe in wireframe-o-vision!)

This would be enough, but because of how SDL works, surfaces need to be locked for pixel-level access and unlocked for blitting. So you also need to:

3. Comment out the lock() and unlock() lines so the blitting works.
4. Comment out the whole "base markers" drawing since anything with getPixel/setPixel will probably crash now since the surface is unlocked.
5. Comment out everything in Globe::blit except the Surface::blit(...) line so it doesn't redraw itself every few ticks (I'll optimize this eventually).

After all this you should have successfully revealed the beast:



Any attempt at rotation will take seconds and the textures don't even match the terrain and there's gaps in the polygons and oh gawd it's just so horrible that I just commented it out to never see the light of day while I cried in a corner for weeks and weeks (seriously though with the huge performance problem there's no point in fixing the rest so I just moved on).

The main reason I was looking was if there were different light levels per texture, but interestingly not, so you'd have to update the texture as your blitting it. Should make things a little more interesting. Either that, or as you read in TEXTURE.DAT, you create several SurfaceSets with the modified palettes to give your different light levels, then you can just blit from whichever source you need.

Yeah palette wizardry is very common in X-Com, and since colors go from light to dark in the palette, you would just shift the palette a bit to the left for each polygon to make it darker. In OpenXcom you can achieve a similar effect with the Surface::offset function.

There are no ocean polygons (except in TFTD) stored in the game files. If I had to guess, the game might just generate a bunch of "ocean quads" itself that scroll horizontally along the flat map depending on the time, and get mapped as a "semi-sphere" on the globe. Or they use some wizardry involving circles or something, what do I know?

If it were me, I'd probably create a hardcoded full sphere polygon list (landscape can draw over the top), but this way you could texture the sea too if you wanted.

Yeah that would be the more sensible option today, but those were different times with only 32K of memory that you couldn't afford to waste or something who knows. Plus it makes the day/night effect look smoother over the ocean.

1753

Programming / Re: Let there be light

« on: July 06, 2010, 08:34:06 pm »

Hmm, perhaps I need to dump the palette out so I can see what I've got to work with. I'm sure if my "shade" variable went negative, or above 6, the globe went psychodellic.

Actually, I dumped the palette out:

At least 16 shades, which will also make a smoother transition.

Well the real globe has actual textures (I haven't applied them because they cause terrible performance for some mysterious reason), which is probably why there's 16 shades of each colour but only 9-10 used for the day/light effect.

If necessary you can just have a min/max value to prevent the globe going psychedelic.

On with the thinking cap.


Also, one last thing. As you noted that there are shades of ocean, you're just drawing a blue circle. Are there ocean polygons that are just not being drawn yet? or is that going to need some wizardry to paint?

There are no ocean polygons (except in TFTD) stored in the game files. If I had to guess, the game might just generate a bunch of "ocean quads" itself that scroll horizontally along the flat map depending on the time, and get mapped as a "semi-sphere" on the globe. Or they use some wizardry involving circles or something, what do I know?

For future reference, I'd suggest checking out:
https://www.ufopaedia.org/index.php?title=WORLD.DAT
https://www.ufopaedia.org/index.php?title=PALETTES.DAT

1754

Programming / Re: Let there be light

« on: July 06, 2010, 05:33:02 am »

What, showing off without a hint of code??? How dare you!

Very nice work! Looks a lot less gradual than the X-Com effect though, I presume you're not done yet?

I've been playing around with the code
https://www.youtube.com/watch?v=VnQjsGGmeNk

Variable Globe::_save is never populated (I added it to the constructor)

It's populated by Globe::setSavedGame.

Day to night palette appears to be 6 shades

I just tried it myself in the original, you're right that the ocean has 6 shades, but each land polygon seems to have 9-10 shades.

1755

Programming / Compiling on Cygwin

« on: July 06, 2010, 05:14:00 am »

No problem, I was just curious, and I'm not too familiar with cygwin myself so you caught me off-guard.

Aside from double-checking the library files, my last suggestion would be to try and recompile it from scratch (use "make clean" to delete all the object files and then try "make" again) in case your previous failed attempts are messing it up.