Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Groogy

Pages: [1] 2 3 ... 5
1
Graphics / Each target with its own context
« on: January 18, 2016, 12:19:53 am »
Hey! Long time since I've been posting here but if I am gonna return might as well return with some nagging :D

Anyway so been playing around with SFML lately on my free time and noticed that each render target is its own OpenGL Context. I think it has always been like that but I noticed an issue with it because of it. Because of them being their own individual context it means that you can't share certain buffers between the different render targets, stuff like VBO's.

Wondering if that could be up to debate for changing in the near future? There isn't really any reason as far as I can see that the FBO's under the render texture can't rely on the Window's opengl context. If I remember correctly when render texture was first implemented this was done as a lazy way to ensure there will always be an active opengl context. Though Laurent will have to correct me on that one since that's years ago.

2
General / Reviving rbSFML
« on: October 18, 2015, 12:52:38 pm »
Hey! Long time since I wrote here but felt it was time to return. I am currently in the process of reviving rbSFML and rewriting the binding from scratch to clear out a lot of old errors that had been made and make maintenance of the library less time-consuming so I don't have any excuse anymore to not keep it updated  ;D

The new revived version can be fetched for now at: https://github.com/Groogy/rbSFML/tree/rebirth

I have only implemented sfml-system in the new branch, the configuration files are just done as "just to work" and I have only tested this so far with Matz Ruby Implementation and on Windows. 

So far not the most interesting but I felt like I should put up a life pulse of the project that it is being reanimated from the dead. In this implementation I am also making my own binding language as I felt Rice wasn't good enough so when rbSFML is done, writing C++ additions to it to expand with your own stuff should be pretty easy.

3
Graphics / Transformable initial state not identity
« on: January 27, 2013, 02:20:52 pm »
Was experimenting around a little and while doing my BDD-based tests I noticed a funny thing. It isn't really a bug but it could be quite unexpected if you don't look in sf::Transformable's implementation.

A sf::Transformable that has been newly created with no changes, I would expect it's transform to be identity. It sort of is but because of an implementation detail in C++ and floats this will fail:

entity.transform.should == Transform::IDENTITY

Looking at the matrix inside the transform I get:
[ 1.0,  0.0,  0.0, 0.0,
 -0.0,  1.0,  0.0, 0.0,  
  0.0,  0.0,  1.0, 0.0,
  0.0,  0.0,  0.0, 1.0]

That negative zero comes from when the transform is generated by the sf::Transformable::getTransform function. The value that is causing this is the sys variable.

float sys    = m_scale.y * sine;

The result itself isn't wrong but I just noticed this when doing my behavior specifications tests and I wanted to guarantee that an unmodified entity has a transformation equal to Identity. And no don't come ruining the thread now with "floating point comparison is dangerous". Yes it is but this is for identity which is a constant value and should always be the same. If you fail to compare against identity then something is wrong.

So yeah, posted this here instead of on Github because i don't really find it a bug. But maybe you Laurent are still interested in solving it? Maybe provide a isIdentity() query function or something?

4
General discussions / Survey for SFML Book
« on: November 17, 2012, 02:35:48 pm »
Hi! Well as we are getting progress on the book I thought it would be nice to get information from beginners here on the forum and see what they think.

https://docs.google.com/spreadsheet/viewform?formkey=dERsdmNZTTM5dU4zLTdpQ2RmekJ0V2c6MQ#gid=0

Please answer it so we can write appropriate to newcomers to SFML and game development. No matter how much we try to imagine we will never have that perspective as all of us writing is quite experienced. So we really are dependent on your answers :)

5
Java / Possible to create an extension
« on: November 03, 2012, 02:31:36 pm »
Hi!

I'm just wondering for future of my rendering pipeline I will need to write to multiple framebuffers in one shader and have HDR formats. I'm more or less porting my rendering pipeline from my ruby project to Java and I had created an "extension" where these were supported in Ruby. I'm wondering if there's any simple way to do that in Java? I'm thinking I create a new library called, sfml-extension with these stuff, exactly what would I need to do and would it work pain free together with the Java objects of SFML if I myself created the Java interface?

6
Java / Final members on vertices and vectors
« on: October 27, 2012, 12:50:17 pm »
Hi! The members of vertices and vectors(and probably other classes) are final. I understand why you've done hat but can you somehow get that removed? Cause it's really annoying to work with.

In the end it will also be inefficient if I have to allocate new objects at runtime just because I want to change vertices at runtime, let's say, a custom animation?

Is it possible to have it read-write somehow? Maybe add set/get methods? I don't really know the function call overhead on Java but I guess declaring the class or the methods final might help with that?

Edit: Just so you don't think I only want this for performance reason. I don't really care that much about it and I know the GC among other things are pretty fast here with temporary objects. But it's just inconvenient to always allocate a new object instead of being able to change it. In some cases it makes sense, vectors can make sense with it but vertices is just plain hard to work with if I can't change it's members.

This is just painful:
this.vertices = new Vertex[4];
this.vertices[0] = new Vertex(new Vector2f(-0.5f, -0.5f), new Vector2f(0.0f, 0.0f));
this.vertices[1] = new Vertex(new Vector2f( 0.5f, -0.5f), new Vector2f(1.0f, 0.0f));
this.vertices[2] = new Vertex(new Vector2f( 0.5f,  0.5f), new Vector2f(1.0f, 1.0f));
this.vertices[3] = new Vertex(new Vector2f(-0.5f,  0.5f), new Vector2f(0.0f, 1.0f));

7
Java / Unable to find native library libsndfile-1.dll
« on: October 20, 2012, 01:56:25 pm »
Well I just tried to launch my application from outside the IDE and it fails on me and I don't know what I am doing wrong. I get this error message:

Quote
$ java -jar GameApplication.jar
Exception in thread "main" org.jsfml.JSFMLError: Could not find native library i
n the classpath: windows_x86/libsndfile-1.dll
        at org.jsfml.SFMLNative.loadNativeLibraries(Unknown Source)
        at org.jsfml.SFMLNativeObject.<init>(Unknown Source)
        at org.jsfml.window.Window.<init>(Unknown Source)
        at org.jsfml.graphics.RenderWindow.<init>(Unknown Source)
        at graphics.RenderWindow.<init>(RenderWindow.java:17)
        at GameApplication.<init>(GameApplication.java:21)
        at GameApplication.main(GameApplication.java:13)

Weird thing is that I am running 64 bit windows and is compiling everything for 64 bit windows. Could it be something wrong here? Though weird how Netbeans would be able to solve it, am I launching the application somehow wrong?

Netbeans puts the libraries in it's own folder called lib in the distribution folder of the project, don't know if that can somehow affect it?

8
Feature requests / Copy texture onto another texture
« on: October 09, 2012, 10:41:45 pm »
As far as I could see not much were written in the forum about this and the assignment/copy constructor seems to turn the texture to an image before creating a new texture. I am just wondering if there is a reason why you are not using directly the copy functions for textures provided by OpenGL? As far as I can see they exist in very old versions of OpenGL as well so it should be compatible.

While we are at it can't you create a update function like you have for images but for textures instead? Where you can copy a rect from one texture to another without going trough render textures? Would make things more simple.

Do you need a usecase? I want to generate some textures at runtime and currently I have to go trough sprites and render textures to get that. Works so far but later I can't move that data to a texture efficiently without having to make it into an image first which I will need.

9
Java / JOGL and JSFML
« on: September 22, 2012, 01:45:17 pm »
Do you guys know of any way to use JOGL with JSFML? I am trying right now but it doesn't seem to work like in C where OpenGL only works on the current context. In JOGL it seems to be that you have to somehow aquire a context object to work with.

Just checking if someone already has solved this or if I should go ahead and try find a way?

10
General / 2D Walls with perspective trough vertex array speed problem
« on: August 21, 2012, 07:02:15 pm »
Hi!

I have a game as a side project for fun that I also use to verify that the Ruby binding is working as intended. Anyway I've reached a problem I would need an outside look on as my thought process has become stuck. The problem is a general programming problem so even if you don't know any Ruby you will be able to help me with new ideas that I couldn't think of ;)

As I normally work with 3D and so on I thought it would be fun to see if I could make a game with fake 3D and build a game from that. That has already been solved and works just fine and efficiently. Problem I have to solve is that when the camera moves the order of the walls have to be rearranged so they draw over each other correctly(since SFML doesn't allow the use of depth buffer). Since this is being done in Ruby it's pretty slow. As soon as the rebuild runs the update time spikes and this builds linearly with the amount of walls I have. Currently the spike isn't that big, just takes Ruby around 1000 microseconds to build the walls you see on the image.



But that's only 28 walls. The plan is to have a big and vivid world filled with this. So let's say worst-case scenario is a big city with large buildings so at any given time we might have around 500 walls showing on the screen. That would result in around 17.8 milliseconds of thinking time and resulting on less than 60 FPS on my hardware which is all of the latest. Of course that's not acceptable as it won't work as the development progresses. What I want is solutions in how to make this work better, I am out of ideas.

class TileArea
  def rebuild_wall_vertexes(camera_position)
    for layer in @wall_vertex_arrays
      layer.clear
    end
    for wall in @walls
      rect = wall.display_rect
   
      min_tex = wall.type.texture_offset
      max_tex = SFML::Vector2.new(min_tex.x + WallType::Size.x, min_tex.y + WallType::Size.y)
      layer = @wall_vertex_arrays[wall.position.z]
   
      wall.sort_directions(camera_position)
      for direction in wall.directions
        case direction
        when :south then
          layer.append(SFML::Vertex.new([rect.left, rect.top + rect.height], [min_tex.x, min_tex.y]))
          layer.append(SFML::Vertex.new([rect.left, rect.top + rect.height], [min_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top + rect.height], [max_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top + rect.height], [max_tex.x, min_tex.y]))
        when :north then
          layer.append(SFML::Vertex.new([rect.left, rect.top], [min_tex.x, min_tex.y]))
          layer.append(SFML::Vertex.new([rect.left, rect.top], [min_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top], [max_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top], [max_tex.x, min_tex.y]))
        when :west then
          layer.append(SFML::Vertex.new([rect.left, rect.top + rect.height], [min_tex.x, min_tex.y]))
          layer.append(SFML::Vertex.new([rect.left, rect.top + rect.height], [min_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left, rect.top], [max_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left, rect.top], [max_tex.x, min_tex.y]))
        when :east then
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top], [min_tex.x, min_tex.y]))
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top], [min_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top + rect.height], [max_tex.x, max_tex.y]))
          layer.append(SFML::Vertex.new([rect.left + rect.width, rect.top + rect.height], [max_tex.x, min_tex.y]))
        end
      end
    end
  end
end

class Wall
  def sort_directions(camera_position)
    position_x = @position.x * WallType::Size.x + WallType::Size.x / 2
    position_y = @position.y * WallType::Size.y + WallType::Size.y / 2
    if(camera_position.y > position_y && (@directions.first == :south || @directions.last == :north))
       @directions.reverse!
    elsif(camera_position.y < position_y && (@directions.last == :south || @directions.first == :north))
      @directions.reverse!
    end
  end
end
 

The rebuild method is only called when needed and even only on specific intervals. The vertex code can be optimized with not clearing and reusing the already in place vertexes but it doesn't give much(I tried but there is a visual bug in rbSFML that will be fixed soon and then I'll apply it). As far as I can see I need an architectural change in order to make the better of this. Any crazy idea is accepted. Keep in mind I am only interested in a solution for the walls visible on screen.

I have backup solutions but I would like to try and not do them as they are more or less just brute-forcing by providing more power instead of actually solving the problem.

11
C / Loading CSFML functions dynamically doesn't work anymore
« on: June 16, 2012, 11:41:42 pm »
Well the title explains itself. Before I could load CSFML dynamically using the OS functions for that. Now it can load the module successfully but can't find any functions in the module. Have you changed anything? Here's a simple little example of what I mean:

#include <Windows.h>

int main()
{
        HMODULE library = LoadLibrary( "csfml-system-2.dll" );
        if( library == NULL )
                return 1;

        void* func = GetProcAddress( library, "sfClock_create" );
        if( func == NULL )
                return 2;

        return 0;
}

This will fail at return 2; and I can't see why it would.

12
C / MinGW compilation error in Debug
« on: June 16, 2012, 11:13:27 pm »
Hi!

Trying some new stuff out and as I fetched the new version of the API I got this problem:
[ 44%] Building CXX object src/SFML/Graphics/CMakeFiles/csfml-graphics.dir/Circl
eShape.cpp.obj
C:\Users\Groogy\Documents\Work\CSFML\src\SFML\Graphics\CircleShape.cpp: In funct
ion 'sfTransform sfCircleShape_getTransform(const sfCircleShape*)':
C:\Users\Groogy\Documents\Work\CSFML\src\SFML\Graphics\CircleShape.cpp:162:5: er
ror: could not convert '0' from 'int' to 'sfTransform'
C:\Users\Groogy\Documents\Work\CSFML\src\SFML\Graphics\CircleShape.cpp: In funct
ion 'sfTransform sfCircleShape_getInverseTransform(const sfCircleShape*)':
C:\Users\Groogy\Documents\Work\CSFML\src\SFML\Graphics\CircleShape.cpp:172:5: er
ror: could not convert '0' from 'int' to 'sfTransform'
mingw32-make[2]: *** [src/SFML/Graphics/CMakeFiles/csfml-graphics.dir/CircleShap
e.cpp.obj] Error 1
mingw32-make[1]: *** [src/SFML/Graphics/CMakeFiles/csfml-graphics.dir/all] Error
 2
mingw32-make: *** [all] Error 2

It compiles perfectly with release settings but only fails in debug and I don't know why.

Update: Got the same with Visual Studio 10

13
General / OOD question for Instance-Model relationship
« on: May 16, 2012, 02:02:22 pm »
Hi!

Well I am working away on my game under code-name Ymir I just realized something I did not like at all. My relationship between an instance and model is very straightforward. The instance has an aggregate to the model and calls the models render function.

What I am asking for is more or less a better design to this than I already have in place. The problem there is right now is that the model classes can easily grow very, very, very large(speaking from experience).

I'll write the code in ruby as I feel it's much easier to write and to give a good impression of the whole easily.
The following code is a simplification of a instance-model node hierarchy.
class Instance
  def initialize( model_mesh )
    @model_mesh = model_mesh
    @transformation = Ymir::Transform3D::Identity
  end

  # ... more code, like state modifying methods...

  def render( shader )
    @model_mesh.render( shader, @transformation )
  end
end

class ModelMesh
  def initialize( data, vertex_layout )
    @vao = generate_vao
    @num_triangles = data.size / 4
    # And all other OpenGL stuff to setup here

    # Retrieve the attribute locations from the vertex_layout
    # and bind them to the vao
  end

  def render( shader, transformation )
    shader.bind()
    bind_vao( @vao )
    # Bind buffer objects
    draw_arrays( Triangles, 0, @num_triangles )
    # Unbind buffer objects
    shader.unbind()
    bind_vao( 0 )
  end
end

Though what I am thinking is that you want to separate code and data. The ModelMesh class is logically more or less a pure data class and should only have code to manipulate this data(like modifying the mesh or opengl states associated with this mesh and so on). But render should/could be moved outside to another class responsible for just that, rendering of meshes.

Now a fast naive thought would be that Instance would be responsible for this but not really, Instance is a instanciation of a model so it only knows the information and instructions for this instance. Which would be more or less states like transformation and etc.

I am thinking to create a new class just responsible for rendering called RenderTechnique. Though where would it be placed? Should Instance own an instance of this class and use it to render model mesh? Or should it be outside? How would it relate then in a more bigger scale? This is where I get uncertain. Is there any common design pattern I've missed that would help me out here? This is most probably the design I will go with but I am still interested in hearing in opinions on other things like why I should keep it in the model class and so on.

For reference you can see it as this: Sprite = Instance, Texture = Model
Though in SFML the Sprite itself now how to draw itself using the given Texture.
I can do it just as SFML of course and have it in Instance. But I am developing a 3D game where I will want to be able to switch between different rendering techniques easily depending on context (Different shaders, Normal Batching, Instancing and so on). It's possible with having everything in Instance/Model but it will get pretty big in the end and having this functionality moved out to a new set of classes it get's easier to switch and the separate classes become much smaller.

Also don't be afraid to just say "You are over-thinking this, just do it like SFML does it" :)
Because I usually do. But I like to think or talk about things like this ;)
And sorry for the wall of text ^^

14
General / Ruby Tutorials
« on: April 21, 2012, 05:30:34 pm »
Alright I'll be writing some tutorials for Ruby pretty soon. I'm just checking what people want? If they are interested in tutorials at all and where do they want them? Do you guys want them here on this forum? On the SFML website or Wiki? Or maybe you want it on it's own webpage? Because I can do whatever.

I am also wondering what kind of format you guys want it? Text or video? Or both? If you have anything special you want me to cover like optimizations in ruby and "Good practices" and stuff like that I can include that as well but if I add further things that goes outside rbSFML and more to general Ruby then I have to separate it out.

15
Graphics / sf::Image and sf::Texture create function messed up
« on: April 01, 2012, 01:26:36 am »
Well the latest commit to SFML2 have messed up sf::Image and sf::Texture's create function making it impossible to create textures or images. This in it's own turn messed up the internal creation of textures and images for sf::Font so my entire example I was going to show up for rbSFML doesn't work because of that ^^

The concerning code is:
////////////////////////////////////////////////////////////
bool Texture::create(unsigned int width, unsigned int height)
{
    // Check if texture parameters are valid before creating it
    if ((m_size.x == 0) || (m_size.y == 0))
    {
        err() << "Failed to create texture, invalid size (" << m_size.x << "x" << m_size.y << ")" << std::endl;
        return false;
    }
   
    // ... more code...
}

I first thought this was a problem in rbSFML so took me some time to find it ^^
Anyway this was done with the most recent commit and is just a little mistake so thought it wasn't worth putting up on the issue tracker. Though on the odd chance that you would miss it I didn't want to just let it be left hanging for several days.


Edit: Oooh wait, seems to be only in sf::Texture. Though somehow it messes up with fonts so that it tries to create a 0x0 sf::Image so you get an error output.

Pages: [1] 2 3 ... 5