Messages

31

General / Bullet Hell performance and optimization problems

« on: June 16, 2010, 09:34:16 am »

But do you really need DDS optimizations?

Oh definitely!

When you are dealing with thousands of HD sprites DDS is a lifesaver. The vram usage is so much smaller. It's really not even possible to get the same graphics to work on the same hardware.

The average sprite set in my previous game is 1000-2000 sprites at approx 800x400 each for just one character. This fit in at about 80 megs of vram.

With png this is impossible.

32

SFML projects / Excellence (previously Eve Shooter)

« on: June 16, 2010, 09:21:50 am »

I think the attack of your sound fonts need to be adjusted so that every note doesn't sound like a midi. I would try to cut down on the repetition and make it more short and compact to compensate for your lack of experience in making the notes/music fancy.

The ships look good.

I would take the missiles off the sides unless you're going to animate them to fire. Nothing more annoying than weapons you can't use.

The gray ship is also too dark.

Makes me wonder if you have a mac or your gamma is messed up.

Parts of it are almost solid black. To be able to see it well you need to make it at least 65% gray.

If you want it to be 'black' you should add a blue/purple/cyan tint to the gray.

I would make the cockpit glass a brighter and more interesting/shiny/reflective color too like red/orange/blue/green/yellow--see the f22 for what I mean.  

http://farm3.static.flickr.com/2409/2187146138_b2fc5e2c50.jpg
http://upload.wikimedia.org/wikipedia/commons/0/00/F22_Pacific.jpg

Of course not too bright so it looks like a kids toy.

Right now it just looks kinda like a hole and will be even harder to see when they are small.

33

General / Bullet Hell performance and optimization problems

« on: June 16, 2010, 08:46:59 am »

You can use one sf::Vector2f and use Sprite.GetPosition() to set it, transform, and then use Sprite.SetPosition(sf::Vector2f); And just repeat over and over, no?

I think the problem is there are all of these useless vectors floating around doing nothing every time you move a sprite.

It's C#, not C++. So there are no GetPosition/SetPosition, and using "new Vector2" on every call is fine, the GC will take care of the unused memory.

DDS goes directly into video memory without any decompression/work and is much smaller so any time you are moving around lots of texture data it's a lot faster. You may just notice the initial load being faster if you aren't doing anything complex.

It doesn't make any difference, SFML internally handles the pixel data the same way regardless the original file format. The format information is lost right after the loading step.

No get and set? Well maybe the garbage man is a little fat and needs some help.  

Wow that's kind of disappointing to hear that about dds. I assumed that might be true because there were no sf::Uint5 or 565. That's kind of disappointing. A lot of my old tech is based on DDS optimization. I guess I have to write those in myself?

34

Graphics / [solved]Tiles are showing black lines at the borders (1.6)

« on: June 16, 2010, 07:09:51 am »

But your SubRect there is just grabbing the entire image file, defeating the whole purpose.

That's just to test it. You can't see well with the brick because both sides have the same color. If you make it 32x32 it should work.

If you don't think it works try 64x64, take a screenshot and drop the source image on it photoshop it lines up correctly.

35

Graphics / [solved]Tiles are showing black lines at the borders (1.6)

« on: June 16, 2010, 06:50:37 am »

I did this to test and it worked seamlessly:

Code: [Select]


  for (float x = 0; x < get_width+1; x++){
            for (float y = 0; y < get_height+1; y++){

  tTile.zSprite.SetPosition(x * 256, y * 128);

                tTile.zSprite.SetImage   ( Engine.TileSet );
                tTile.zSprite.SetSubRect ( IntRect ( 0, 0, 256, 128 ) ) ;



36

Graphics / [solved]Tiles are showing black lines at the borders (1.6)

« on: June 16, 2010, 06:29:54 am »

The calculations for the tile positions are correct.  I tested it with a 32x32 image of one of my tiles, and it works fine.  But I hate having every tile in its own image, it's annoying to code with.

If I put the SubRect to (0, 0, 32, 32), it'll look fine for a while, but when you start moving, parts of the tiles below and to the right of the topleft tile in the tileset image show up

Well it's hard to tell. On the demo you sent me it's fixed

37

Graphics / [solved]Tiles are showing black lines at the borders (1.6)

« on: June 16, 2010, 05:48:31 am »

Well after taking a glance it looks like your position is off since there is 0,0 start position yet your multiplying it times 32 so it's creating a space.

If that doesn't solve it you can test your tiles to see if there is a hole by setting your clear color to red:  

Engine.Screen.Clear(sf::Color(255,0,0));


UPDATE:I had some free time to test your code with tTile.Sprite.SetPosition( x * 31, y * 31 ); and I was right it works now.

38

Graphics / [solved]Tiles are showing black lines at the borders (1.6)

« on: June 16, 2010, 03:15:29 am »

Well hopefully Laurent knows what's wrong.

I can't really help unless you tell me which SFMLv you are using and post the full code.

39

General / "gdb.exe has stopped responding" codeblocks

« on: June 16, 2010, 02:54:45 am »

Well after installing every version of MinGW and GDB I could find, I found a link to TDM's GCC/MinGW32 build.

http://sourceforge.net/projects/tdm-gcc/files/

it was pretty good actually, I didn't go for the TDM build, but it offered the most recent stable MinGW (GCC 4.5), including the most uptodate GDB (7.1). This seems to be working now, hopefully I wont come across any other compiler/debugging problems...

I recommend using the prepackaged compiler on the SFML page if you are having problems.

40

General discussions / Project CAMP - open-source reflection library for C++

« on: June 16, 2010, 02:49:42 am »

Kinda obstinate eh..

Well I can see one other simple example : with an UI designer, to connect callback functions.

Imagine an UI designer where you save the function name to be called when an action occurs.

With CAMP you would tell which controller object is to be used when loading the UI, and then the GUI would just have to find the method with that name and call it through CAMP.

Without CAMP, how can you define a dynamic link between a function name and your code ? Unless the UI designer produces source code containing a static class of course (as QTCreator does).

Ah, if I'm not mistaken I do this a lot in javscript when creating DHTML interfaces and it's very useful (especially since you want the least code possible for compression). Wow, this sounds like CAMP allows a lot the javascript tricks for dynamically generating/using code so you write less overall.

I need to do some experiments later.

The only thing I"m really concerned about is speed/resource overhead.

41

General / Bullet Hell performance and optimization problems

« on: June 16, 2010, 02:17:13 am »

Well looking at the code above should you really be creating a new vector every time you change the position and draw the sprite?

If the problem is drawing speed you could try saving your images in dds and see if that helps, but I'd look closer at your data creation/management or any unnecessary loops.

X and Y are read-only in Vector2.

Why should saving imgage in dds help? I've never used dds files before.

I know it's read only because every Sprite contains an internal copy so you don't need a new Vector each time.

You can use one sf::Vector2f and use Sprite.GetPosition() to set it, transform, and then use Sprite.SetPosition(sf::Vector2f); And just repeat over and over, no?

I think the problem is there are all of these useless vectors floating around doing nothing every time you move a sprite.

DDS goes directly into video memory without any decompression/work and is much smaller so any time you are moving around lots of texture data it's a lot faster. You may just notice the initial load being faster if you aren't doing anything complex.

42

General / Bullet Hell performance and optimization problems

« on: June 15, 2010, 11:16:30 pm »

Well looking at the code above should you really be creating a new vector every time you change the position and draw the sprite?

If the problem is drawing speed you could try saving your images in dds and see if that helps, but I'd look closer at your data creation/management or any unnecessary loops.

43

General discussions / Project CAMP - open-source reflection library for C++

« on: June 15, 2010, 02:02:40 pm »

Hi, CAMP sounds great. I remember doing serialization in Java many, many years ago.

I believe I used it for networking/file transfer.

I'm curious though, what are the advantages over using a script binding like AngelScript (I was thinking of using that for my GUI setup)?

I assume it would also be good for saving complex game states (which could be reused for netowrking or playback)?


Any other ideas you might have for games/SFML apps?

Maybe a history/undo system?

44

Feature requests / LAME MP3 support

« on: June 15, 2010, 01:15:26 pm »

I'm not playing this game with you. Enjoy your thread.

It's a 'game' to actually use a product before you review it?

I don't even know what you're angry about. A plug-in audio system is great idea and since...

"Today, LAME is considered the best MP3 encoder at mid-high bitrates and at VBR, mostly thanks to the dedicated work of its developers and the open source licensing model that allowed the project to tap into engineering resources from all around the world. Both quality and speed improvements are still happening, probably making LAME the only MP3 encoder still being actively developed."

I think it's at least worth testing if you are a serious developer or care about your audio compression and this makes it a great candidate for plug-in support.

Also, consider the fact that most audio is already in MP3 and converting it to ogg will further degrade the quality. If you cant find a wav or something lossless you are already better off not using OGG.

45

General / Bullet Hell performance and optimization problems

« on: June 15, 2010, 05:47:56 am »

You might not be able to use a single sprite, but you should be able to use a single constant instance of bounding boxes for each bullet sprite identical.

In a lot of bullet hell games the bullets come out in patterns and cannot be altered

Because of this you can do a lot of pre-guessing illusion work for example in growing rings or wave patterns of what the collision/position should be and even the graphicss.

Another example: streams/blocks of bullets can be built into rectangles for collison.

Want to go even further?

Cull collision detection for enemy bullets based on their ability to hit the character. IE, many bullets will be out of range and impossible to hit, especially if you are already surrounding the character with bullets.

Move offscreen bullets instead of destroying/creating them.

Perhaps even flickering your bullet sprites and drawing them every other frame might help too?

Make your bullets out of an sf::Shape?