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.

Messages - greeniekin

Pages: [1] 2 3 ... 5
General / Re: AW: error: redefinition of new
« on: December 22, 2014, 01:35:43 am »
I downloaded SFML2.2 from the all source code on the download page and built it my self.

Though it seems unrelated from linking as I removed the link to sfml and I still get the same error.

It seems to be this section of code in tools.h that is being a hassle
inline void *operator new(size_t, void *p) { return p; }
inline void *operator new[](size_t, void *p) { return p; }
inline void operator delete(void *, void *) {}
inline void operator delete[](void *, void *) {}

While it might seem obvious this is the problem it is not as when I remove the SFML include it all builds fine.
Deleting this section of code is not really an option either as then the rest of the code will not build.

Never mind I worked it out.
The code snipet above was implementing a "placement new".

There is also an include for placement new which can be included by "#include <new> "

presumably SFML calls this somewhere and that is why it is redeclared.
I just deleted the above snipet and put a "#include <new>" there instead

General / error: redefinition of new
« on: December 21, 2014, 11:48:56 pm »
I am using codeblocks on windows.

i added "#include <SFML/Audio.hpp>" to a file now when I compile I get

c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new||In function 'void* operator new(std::size_t, void*)':|
c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new|111|error: redefinition of 'void* operator new(std::size_t, void*)'|
..\shared\tools.h|36|error: 'void* operator new(size_t, void*)' previously defined here|
c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new||In function 'void* operator new [](std::size_t, void*)':|
c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new|113|error: redefinition of 'void* operator new [](std::size_t, void*)'|
..\shared\tools.h|37|error: 'void* operator new [](size_t, void*)' previously defined here|
c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new||In function 'void operator delete(void*, void*)':|
c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new|117|error: redefinition of 'void operator delete(void*, void*)'|
..\shared\tools.h|38|error: 'void operator delete(void*, void*)' previously defined here|
c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new||In function 'void operator delete [](void*, void*)':|
c:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\new|118|error: redefinition of 'void operator delete [](void*, void*)'|
..\shared\tools.h|39|error: 'void operator delete [](void*, void*)' previously defined here|
||=== Build finished: 8 errors, 0 warnings (0 minutes, 2 seconds) ===|

I tried including System instead and same errors the errors do not make sense to me. Soon as I remove the include everything is fine.

here is the tools.h file http://websvn.tuxfamily.org/filedetails.php?repname=tesseract%2Fmain&path=%2Fsrc%2Fshared%2Ftools.h

SFML projects / Re: SFML android port
« on: March 28, 2013, 03:41:31 pm »
*Imagin mad scientist from space voice...that's also a space pirate....and awesome with jectpacks*

They called me mad for not using the android glue code. Mad they said. I called them mad and damn them, they outvoted me.
Now I have shown them. I shall rain fire and brimstone upon those that doubt me.
Well if I can work that into really poor budget. Otherwise it will be more of cursing you from my share house...


On a side note I have done a bit more. Got shaders(mandatory for GLES 2) and some rendering working.
So currently graphics works much like SFML window src works with sub folders representing the os specific part. Except the subfolders are "opengl" and "gles2"

Not much is done here and I am tempted to not make graphics 2d specific. Have features that accept matrix and then have a graphics 2d specific stuff that is specific to 2d and inherits from normal matrix stuff and there there is the potential to use the same code for personal 3d stuff or a seperate 3d library. This way code can be shared as opposed to the current model.

As to the main entry point. I have implemented a hack. When building the examples I include a c++ file with the top part of code. Making it unnoticeable..... in the examples built in cmake. Though outside you would have to include it your self. ><

SFML projects / Re: SFML android port
« on: February 28, 2013, 10:58:38 am »
Decided to do a little more work on this past couple of nights. fleshed out event handling quite a bit. Better support for buttons and even keyboards. Also I have ouya controllers working. With the controllers being sfml joysticks. x and y are the left thumb stick, z and r are the right thumbstick,u is the left trigger and v the right trigger.
Which turned out quite nice.

I mapped the android back button to keyboard escape. Dpad to keyboard arrow keys. Select button to keyboard enter. That is it so far. Means you can write a simple single player game for a pc and it will work on ouya and android. Though if you have multiple controllers on the ouya they will send the keyboard events. You need to use joystick to distinguish them. Which I kind of like the idea of anyway.

I have kind of started on the graphics part. I am looking to use GLES 2. Which is a bit of a pain as it lacks matrix modes and  fixed functions and seems to require shaders for everything. Which does not really match the current design. I thought I read somewhere opengl 3 is much the same. Anyway Unsure exactly what my solution will be. I do not want to have 2 code bases. Especially since I think a fair amount will be similar.

I like some aspects of this. Like simi-colons are a bit nasty when it is bad form not to have and enter after the line. Why not just have a new line and that's it. I have done a lot of programming in javascript and dynamic types can be nice sometimes.

I still, like everyone else, thinks functions should have brackets. It makes things more clear.

Not having braces seems personally weird. I use to program in qbasic and then visual basic. Though i have been doing so much work in php, javascript, and c++ that it just seems weird. I do get it though. Indentation is an important part of making something readable.

SFML projects / Re: TankTank Mutliplayer Project
« on: February 21, 2013, 08:47:06 am »
I have read a couple of ways. One way I read was keeping a log of all turns and movements ect. with their time client side. Then run the commands stepping forward in time since the last state information was received from the server(accounting for lag). This way your character can not continue to get further and further out of sync.

I do not know how this will perform with different pings. Maybe you can have interp between the last estimation and new estimation to smooth it out a little bit. Though the way some games behave when I get some lag I do not think they use Interp.


by turns and movements I mean the commands that cause them like "+foward" and "-foward" in quakeworld.  This way it is relative to the latest updated position state, or whatever other states that are important.

General / Re: Compiling sfml for OSX
« on: December 05, 2012, 02:26:38 am »
I've heard that there has been some issues with using quartz.
That when you run the app on other peoples mac it tells them to go to the website and download quartz.

I figure If I compile it and link statically it will not be a problem. Seems to have worked I have had nothing about installing quartz when just running the sfml examples. Though I also have not packaged them up and tried to install them. Which might be where the issue comes from.

General / Re: Compiling sfml for OSX
« on: December 04, 2012, 02:53:54 am »
I did not realize sfml 2 had a build tutorial yet. Also google failed me all I could find was this page with stuff down the bottom


Though regardless when I generate the unix makefile and execute it from the command line I get the same errors as from generating "codeblocks - unix makefile". Which makes sense I suppose.

I suppose I will download the latest from Laurents git and see if I have any luck there.


Seems downloading the latest one seems to work better.
Now when it tried to build the opengl example it dies because of freetype it looks like.
Was trying to be clever by compiling freetype myself.
seems it is missing symbols for bz2 and gzip

This is more my problem to solve. Thanks a lot for the help.

General / Compiling sfml for OSX
« on: December 03, 2012, 08:55:07 am »

I was recently trying to build the sfml 2 sources on OS X Mountain Lion.
Set up all the build stuff. xcode, command line utils and codeblocks.

I used the cmake gui to set everything up and got it to configure and generate after pointing it to freetype lib.

Open the codeblocks project for it and when I try and build I got this.

src/sfml/SFML/Window/GlContext.cpp 105   error: allocating an object of abstract class type 'SFContext'
src/sfml/SFML/Window/GlContext.hpp 174   note: unimplemented pure virtual method 'setVerticalSyncEnabled'  in 'SFContext'
src/sfml/SFML/Window/GlContext.hpp 161   note: unimplemented pure virtual method 'display'  in 'SFContext'
src/sfml/SFML/Window/GlContext.hpp 193   note: unimplemented pure virtual method 'makeCurrent'  in 'SFContext'
src/sfml/SFML/Window/GlContext.cpp 142   error: allocating an object of abstract class type 'SFContext'
src/sfml/SFML/Window/GlContext.cpp 159   error: allocating an object of abstract class type 'SFContext'
src/sfml/SFML/Window/GlContext.cpp 170   error: allocating an object of abstract class type 'SFContext'

Note: I hand typed this. Posting on a different pc. so excuse typos

When I look in src/sfml/SFML/Window/OSX/SFContext.hpp those functions are defined and are not abstract(no =0).

Also in src/sfml/SFML/Window/OSX/SFContext.mm those functions are defined.

Now I am using it with codeblocks with makefiles

I also tried to do it with generating xcode project from cmake. It also had the same errors. Though lacked the notes.

It is really strange and I can not work it out.

Also I really need to build these myself not previously built binaries.

SFML projects / Re: Survive and Thrive
« on: December 03, 2012, 04:50:06 am »
The Terminator I would love to see some pictures or better yet a video of what you got.

Nexus great article about pointers.
the one that does this
huge_object build_new_object() {
  huge_object ret;
  return ret;

Seems odd as that would make a copy of that huge object. Which could be bad if it was a map.
wouldn't you use an auto_ptr//deprecated
or a shared pointer if you wanted to ever avoid having to delete pointers and the associated annoyance of memory leaks.

I genuinely do not know. I'm sure that guy is much better experienced than I am.

SFML projects / Re: SFML Resource Wrapper
« on: November 11, 2012, 02:41:36 am »
I really like the way this is set up. You could convert existing code with nearly no changes.

You may not need this, but i like it myself.

I have a reloadModified method on my resource manager which goes through and checks the modified date when loaded and what it is now and reloads the file if it has changed.

Then just in main method set it to check every second. I can have my game running in one screen and modifying a file in another and the game auto updates.

Not really useful when your done developing though.

I do kind of get this. Though it is usually not that hard to add a lot of that stuff. I have actually added my own  libs to the sfml cmake build tree for some of these things. Which has made a lot of things much simpler.
Like dateTime, browsing folders, file modified times  and various 3d stuff like a 3d sfmlText.

Problem is when do you stop.

Also if I remember correctly sdl has seperate libraries to download. Like SDL_mixer and the like.
Maybe someone could make a sf::filesystem library to download separately.

Be nicer if there was an easier way to see sfml add on libraries. SDL has that page for it. I think that can be outdone. I know there is the wiki but I am not found of wiki's for some things.

A tip if you go my way is to use WinMerge when your going to update your personal tree with the latest. Makes it so easy.

SFML projects / Re: Collision shapes for SFML
« on: November 07, 2012, 07:35:46 pm »
well yes. Though I feel that does not have much meaning.  In my mind this makes more sense. Though my mind is a scary place. Though I am not wrong either.

SFML projects / Re: Collision shapes for SFML
« on: November 07, 2012, 06:27:13 pm »
Well the talk of the book motivated me because I was thinking what would be good things to teach. Powerful yet learn-able.

The method I am using is very simple. The idea is pretty much the idea ofgetting down low and looking across the top of a table to see if there is any distance between the 2 objects.
And this is done for every single face of an object. The shapes have to be convex, as the check for distance from the line or plane is to infinity.

this is basically used to convert each points position to height from line/plane.
h = normal.x * point.x + normal.y *  point.y;//+d could be added so 0 is the actual position of the plane.

I am not describing it well. I need pictures and I can not remember the name.

Essentially the idea is changing the perspective to face down the line. Then you only need to worry about using one axis.

I originally saw it with 3d planes using
h = normal.x *  point.x + normal.y *  point.y + normal.z *  point.z+d;

SFML projects / Collision shapes for SFML
« on: November 07, 2012, 04:59:06 pm »
With the talk of the SFML books I was thinking about collision detection and a simple solution.
I have created a function at the moment which accepts sfml shape objects. So you can also draw the shapes your using for debugging or in the actual game.
It works with all the shapes transformations. Such as translation, scale and rotation.
The actual code for this is about 100 lines
This is an example of an person collides with another object it will keep the object out of the wall.
    sf::ConvexShape polygon;
    sf::CircleShape person;
    sf::Vector3f intersect;
    sf::Vector2f pos;
    if(collision(person,polygon,intersect,pos))//order of shapes is important as intersect direction will be reversed

Here is a little demo I was testing. Warning the physics is not even an attempt at proper physics. Though the collision detection works well and you could expand on this with whatever logic you want.


I am not sure what the plan should be next. Should I create Classes for these and that way classes can contain multiple convexShapes to make more usefull collision objects. Should I go as far as some lightweight physics? In any case I am not going to have it do any scene management.

Pages: [1] 2 3 ... 5