Messages

1

SFML projects / Anti Photon Engine - A SFML driven (realtime) Raytracer

« on: August 11, 2008, 10:27:18 am »

I really like your raytracer, it produces high-quality graphics. Too bad my CPU is too slow to get some nice FPS (currently I get < 1 FPS).
Keep up the good work!

Thats unexpected, but good to read. As we are working with big buffer objects(96bit Colors, Ray gc, etc.) its good to have more then 1GB RAM and 200Mhz clock(that would be 800 for DDR2).

On my dev machine, an amd X2 4600+ with 6GB of high performance DDR2 RAM, I get for most demos between 2 and 7 fps and for Solar System in the shipped way about 40 to 44. The big difference how ever seems to be produced by the sceduler of ubuntu, as linux64 builds seemed to be about 50 to 100% faster then the windows ones even in wine demos seem to run a bit faster.

If you reduce resolution to about 200x200 you should get "realtime" by now...well but there is a lot of work and conversions from C++ to SSE asm in some places deep inside you wont see, so you can get 30FPS on some sort of quadcore(whats btw below our target platform, as we thought it would take us much longer to add so much functionality) in some normal low resolution such as 800x600, what would be okay for real applications.(If you start devolepment at this resolution and you finish a year later, the advancement in our and at hardware side will be enaugh to allow resolutions around 2M Pixels.

2

SFML projects / Anti Photon Engine

« on: August 10, 2008, 07:05:16 pm »

For those who dont want to download my package, here are some screenshots I put together:



The big one is a solar system demo. The background stars texture has a too low resolution, thats not our fault, as we allow any size for textures as long as it fits into RAM.

Small imagase top to down:
First is a point based camera that moves around in a box with two spheres and a flat blue mirror. You see things from short above the "glas" sphere.

Second is a short demo of the pixel shading system. It creates some sort of edge detection and greenish depth based fog. Both takes about 10 lines of C++.

The last image is done with only 80 lines of code at all. It uses two textures for normal mapping and three for diffuse/emissive color. The scene contains 0! Triangles: There is one ellipsoid and six quads.(Quads are exactly as fast as triangles so there is no need for them)


It would be nice to have more feedback;)

3

SFML projects / Anti Photon Engine - A SFML driven (realtime) Raytracer

« on: August 10, 2008, 06:50:06 pm »

For those who dont want to download my package, here are some screenshots I put together:



The big one is a solar system demo. The background stars texture has a too low resolution, thats not our fault, as we allow any size for textures as long as it fits into RAM.

Small imagase top to down:
First is a point based camera that moves around in a box with two spheres and a flat blue mirror. You see things from short above the "glas" sphere.

Second is a short demo of the pixel shading system. It creates some sort of edge detection and greenish depth based fog. Both takes about 10 lines of C++.

The last image is done with only 80 lines of code at all. It uses two textures for normal mapping and three for diffuse/emissive color. The scene contains 0! Triangles: There is one ellipsoid and six quads.(Quads are exactly as fast as triangles so there is no need for them)


It would be nice to have more feedback;)

4

SFML projects / Anti Photon Engine - A SFML driven (realtime) Raytracer

« on: August 08, 2008, 07:47:09 pm »

Its the band of my coautor Jonathan.

Anyone who wants to become tester is welcome. I would give you individual support if you wish:)

5

SFML projects / Anti Photon Engine - A SFML driven (realtime) Raytracer

« on: August 08, 2008, 02:17:30 pm »

I wrote together with a friend a lib that allows the creation of CPU based realtime raytracing applications. Realtime is atm. not 2 MegaPixel fullscreen with 16 sampels perpixel, but hopefully it will be some day.
We just finished our work on 0.2 version, which is the first version that offers others to use our lib, as it includes not only demos, but also the headers and libs needed for development, documentation and some tutorials.

SFML is used to implement the ScreenBuffer, that is a device that talks with the OS and puts Pixels onto the screen.
In 0.1 we used also Threads but decided to move to boost.

As for 0.2 the libs are not fast and we got a lot of features that are currently unused we decided to work on a 0.3 version which will look the same, that means programmers wont need to change their code.
This 0.3 version will bring you needed speed and implementations and hopefully far more tutorials.

Have fun with this: http://www.determinationmusic.de/package.7z

EDIT: Any feedback is very welcome!

6

SFML projects / SFML space -> Getting an spaceshooter working on unix/lin

« on: June 18, 2008, 08:47:15 am »

@Christoph: Du solltest unicode integrieren, dann tut das mit den ö auch.

Looks like a good demonstration of what can be done in short time with sfml:)

7

Window / [Solved] Memory leak in svn; how to make debug libs

« on: June 02, 2008, 11:27:42 pm »

Hmm okay.

8

Window / [Solved] Memory leak in svn; how to make debug libs

« on: June 02, 2008, 10:19:55 am »

I got a leak of about 260k by just creating a RenderWindow on Linux. If you tell me how to do a debug build without completly rewriting the makefiles I can maybe fix it for you.
Thats what valgrind says:

Code: [Select]

==9464== 262,140 bytes in 1 blocks are definitely lost in loss record 119 of 119
==9464==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
==9464==    by 0x409C1E1: (within /usr/lib/libGL.so.169.12)
==9464==    by 0x4091037: glXCreateContext (in /usr/lib/libGL.so.169.12)
==9464==    by 0x5037738: sf::priv::WindowImplX11::CreateContext(sf::VideoMode const&, XVisualInfo&, sf::WindowSettings&, XVisualInfo, unsigned long) (in /usr/lib/libsfml-window.so.1)
==9464==    by 0x5038916: sf::priv::WindowImplX11::WindowImplX11() (in /usr/lib/libsfml-window.so.1)
==9464==    by 0x5034D02: sf::priv::WindowImpl::New() (in /usr/lib/libsfml-window.so.1)
==9464==    by 0x50320B4: sf::Window::ForceContextInit() (in /usr/lib/libsfml-window.so.1)
==9464==    by 0x50323C6: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/lib/libsfml-window.so.1)
==9464==    by 0x528155F: sf::RenderWindow::RenderWindow(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/lib/libsfml-graphics.so.1)
==9464==    by 0x40F64F: ape::std::sfmlRenderer::sfmlRenderer(unsigned, unsigned, char const*, unsigned) (sfmlRenderer.cpp:9)
==9464==    by 0x402726: main (main.cpp:21)

9

Feature requests / Re: Import 3D graphics

« on: April 04, 2008, 07:23:56 pm »

It would be very useful if it's possible to import 3D graphics into a window. In the irrlicht engine this is already implemented.

I dont think so, as you can not draw 3D(efficiently) with sprites :twisted:

10

General discussions / Draw buildings with 2d iso Diamond

« on: March 27, 2008, 05:38:45 pm »

you need to draw them top down(that means higher y first in most cases).
I think in most cases the size of the buildings image wont matter, but your artist should know your 64x32 ratio, as this will make a difference for him.

11

Graphics / Re: Why Sprite floats are evil

« on: March 23, 2008, 11:44:20 pm »

I see to possible solutions:

Uhm?
double is your friend;)
cast it to float for screen coordinates and you wont have ANY problems;)
btw. double is not slower on 64bit systems and you dont need to worry of memory or precission in your project...you need a really big project to waste a normal systems total memory with a 2D game. (unless you didnt notice delete:P)

12

Window / Window creation (Linux)

« on: March 23, 2008, 11:37:04 pm »

Same problem on Ubuntu 7.10 64bit with SFML 1.1
I never noticed that but it seames as it has been there all the time.

13

Feature requests / More Keys for Press/Release events

« on: March 23, 2008, 11:32:27 pm »

Thats ok, BUT there is no real difference between the hex and the unicode.
Both are numbers on nearly the same level:)

14

General discussions / Linux static build

« on: March 23, 2008, 11:30:42 pm »

Afaik 1) is ok and by static linking you cant produce any kind of error.
BUT what you want to avoid, is a big strength of all linux distros with a package manager(that is ­~all), as they will provide you with external libraries if they arent yet installed.
That will lead to a less bloated system as you'll have the same code only once.

15

Feature requests / bool sf::Sprite::CheckCollosion(Sprite param)

« on: March 22, 2008, 11:42:56 am »

How do you build a collision outline from a sprite with random transparent pixels ?

Forget about the outline I'd say...one could add alpha and check if it's at any point above 1...but that would be an expensive operation.