Messages

541

Programming / Re: [Solved] Textures

« on: July 10, 2010, 08:02:58 pm »

I did that, because yeah... I completely forgot about that point, despite writing it in the top of the post 

542

Programming / Re: Let there be light

« on: July 09, 2010, 09:53:41 pm »

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).

That's fine, I had accounted for that.

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.

hehe, okay. I'll post a topic before I start looking at anything.

Oh, on a completely backwards note. we're going to have to undo a portion of the texture update. Whilst splitting out the globe and overlays might look cleaner anyway, the whole buffering of the globe was based on the fact that if you didn't rotate, it stayed the same. However, that completely neglected daylight rotation...


Here's the first look...
https://www.youtube.com/watch?v=JY5eJ_m2DlA

Edit: Attached patch

543

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

« on: July 09, 2010, 07:14:00 pm »

Which chapter?

544

Programming / Re: Let there be light

« on: July 09, 2010, 05:03:44 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

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 

545

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

« on: July 09, 2010, 09:09:55 am »

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

546

Programming / Re: Textures

« on: July 08, 2010, 10:35:00 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.

Wasn't really much trouble, define a new function, copy and paste the code, make some minor alterations... Took longer to find out what the problem was than to fix it  

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.

Yeah, I must admit, when I saw all your surfaces being created as SDL_SWSURFACE, I was wondering if that was the bottleneck and switched them to SDL_HWSURFACE. It didn't work, so I moved on, where I noticed the SDL_RLEACCEL flag, I though, there's no RLE encoded images here, so I did a quick search and also saw several bug reports linked to it. That led me to remove it, and hey presto...

Edit: Oh, the code doesn't take into account the zoomed textures, but that should be trivial to add

547

Programming / Re: Textures

« on: July 08, 2010, 09:45:09 pm »

Here you go... All working.

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

548

Programming / Re: Textures

« on: July 08, 2010, 09:24:18 pm »

Okay, the attached patch file makes several changes.

1. Changes the SurfaceSet like my previous file uploads
2. Buffers the globe in _world
3. New drawWorld() method, only called when rotating or zooming
4. Reduced loop count in drawWorld() (was from draw())

This has sped things up q bit, and when not rotating, plays very nicely.
Rotating and zooming still locks up for about 3-5 tenths of a second.

Interestingly, if you comment out the following lines

Code: [Select]

 if( !backFace )
    texturedPolygon(_world->getSurface(), (Sint16*)&x, (Sint16*)&y, (*i)->getPoints(), _texture->getFrame((*i)->getTexture())->getSurface(), 0, 0);

Whilst you can't see the land, it rotates rapidly... your bottleneck must be here


Edit: Interestingly, if you leave drawWorld() alone, and comment out the draw() line:

Code: [Select]

SDL_BlitSurface( _world->getSurface(), &copyRct, this->getSurface(), &copyRct );
Again, it doesn't draw the world (at least to the screen, but it is blitting the textured polygons), and it's fast again... There must be something...

549

Programming / Re: Textures

« on: July 08, 2010, 01:55:54 pm »

I understand what you're saying, but I probably didn't explain myself very well.

Globe::draw() draws effectively two things: Firstly, the actual planet, and Secondly, any bases, craft and other overlays.

If you add line

Code: [Select]

cout << "Globe:draw();";to the top of the draw function, you'll find this is rendered every frame (which makes sense to animate the bases and craft). However, it also means you're rendering the globe using texturedPolygon 20+ times per frame, every frame.

Can I suggest adding the following to Globe

Code: [Select]

 private:
    Surface *_world;
    void drawWorld();

drawWorld() then does performs the polygon enumeration and texturedPolygons onto the _world surface
draw() would then perform a bit of _world onto this->getSurface(), as well as drawing the bases and craft.

Globe::zoom() and Globe::rotate() would then have a call to drawWorld() to update the planet as it is changed.

Does this make more sense? If not, if I get chance tonight I'll fix up the code and post a patch file.

550

Programming / Re: Textures

« on: July 08, 2010, 12:34:51 am »

Yeah, sorry, like I said in your other topic, didn't realise there was a Patch feature. I'm pretty new to SVN, we use SourceSafe at work.

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

551

Programming / [Solved] Textures

« on: July 07, 2010, 10:07:26 pm »

I split this off from the lighting thread because they're not really related.

Problems with texture mapping

• Textures drawn incorrectly
• Black spots from polygon bounds
• Slow as a snail in a coma

Addressing point 1

Had to change the way you approached texture bundles. I've modified the SurfaceSet class (code files should be attached to this post). Basically, rather than 1 big Surface (which was being tiled on the texturedPolygon routine, causing the weird image), it creates a seperate Surface for each texture.

Also, Globe.cpp was modified in the Globe::setTexture method, when enumerating polygons

Code: [Select]

void Globe::setTexture(SurfaceSet *texture)
{
_texture = texture;
_texture->setPalette( this->getPalette() );
draw();
}

and Globe::draw was modified thusly

Code: [Select]

texturedPolygon(getSurface(), (Sint16*)&x, (Sint16*)&y, (*i)->getPoints(), _texture->getFrame((*i)->getTexture())->getSurface(), 0, 0);

Addressing points 2 & 3
I'm going to have a play at trying to re-write the texturedPolygon, hoping to improve performance, and might fix the polygon edges... We'll see...

552

Suggestions / Re: Starting Base

« on: July 07, 2010, 02:26:31 pm »

Aye, you're probably right. Maybe just build an editor that allows you to create these templates, and you select one as you start the game

553

Programming / Re: Let there be light

« on: July 07, 2010, 11:56:51 am »

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).

Actually, I did these instructions, it just left me with a blue globe (tho I might have forgot to change the surface lock). I'll have another look later

I can't see the image at work (it's blocked), but I'll fiddle with the code

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).

Hmmm, I might take a look at this, see if I can help out any, as I have a cunning plan how to perform this operation quickly...

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.

Thanks for the heads up on that.

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.

Oh I knew why they didn't do it UFO, but I'm saying for OpenXcom you should. That said, TFTD had polygons for the seas, although I don't think they had as many for the land.

554

Programming / Re: Let there be light

« on: July 06, 2010, 11:13:50 pm »

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.

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.

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.

555

Suggestions / Starting Base

« on: July 06, 2010, 09:30:47 am »

Could I suggest a starting option that instead of getting a default base when you start the new game, you use the same screen when building the 2nd, 3rd, 4th bases etc. and just get to place the access facility, then you have to build and buy all your stuff.

That way you could really set out the base the way you wanted.

I was also thinking, is it worth holding off aliens for the first month so your score doesn't plummit, but then, if this happened in real life, you wouldn't get a "Hello, we're about to invade, would you like to prepare". So you could maybe have that as an option too.

Just a thought