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 - Syntactic Fructose

Pages: 1 2 [3] 4 5 6
31
Graphics / Re: How about getting the Font in xCode 5?
« on: June 01, 2014, 07:25:18 am »
From what I can gather, resourcepath was supposed to be your file path that would be loaded into your font. I also noticed you're mentioning two different files, BoxFont.ttf and sansation.ttf . Make sure you load the correct file name first off, secondly you could check if the font loaded correctly:

if (!font.loadFromFile("BoxFont.ttf"))
{
    // error...
}

and then from there add the font to a sf::text and write

sf::Text text;
text.setFont(font);
text.setString("Hello world");
text.setCharacterSize(24); // in pixels
text.setColor(sf::Color::Red);
text.setStyle(sf::Text::Bold | sf::Text::Underlined);

...

// inside the main loop, between window.clear() and window.display()
window.draw(text);

32
Graphics / Re: How about getting the Font in xCode 5?
« on: June 01, 2014, 05:47:55 am »
If I'm reading this corrently: if your .ttf is in the same directory as your main.cpp you wouldn't need to specify folders e.g.
font.loadFromFile("sansation.ttf");

33
I solved the problem, I removed CodeBlocks' MinGW 4.8.1 compiler, and replaced it with TDM GCC 4.8.1. It seems to be working just fine now. Thanks for the help anyways!

By the way, syntactic I love your name :). It gave me a good laugh a couple of minutes ago.

haha thanks, It took me awhile of starting at the screen to think of this name  :P

34
Graphics / Re: Spacing error
« on: May 31, 2014, 06:45:11 pm »
Removing your first post was a very bad idea. Now nobody can understand what's going on in this discussion. Don't do that again please.

you stole the words from my mouth. It's a bummer when questions like these show up in google searches and suddenly the post is empty.

35
Window / Re: SFML OpenGL context 3.3 not working?
« on: May 31, 2014, 06:38:07 pm »
Any ideas? I'm not sure if SFML is actually allowing the use of
f
since it's just a warning, but I'd like to get to the bottom of this.

36
Window / Re: Key detection issues.
« on: May 31, 2014, 06:34:59 pm »
I've experienced less buggy code handling input outside the event loop, I'm not sure if this is bad practice but it works 100% of the time for me.

I actually check for input using a separate function in my OpenGL SFML programs, and I've never had input issues. Gist: https://gist.github.com/Syntaf/ceb0900e446af064af72

37
You should be able to find
libiconv2.dll
in your
mingw\bin\libiconv2.dll
folder, I would first check to make sure it exists secondly are you using a git repository? Or just a normal project folder?


38
While I can totally relate to building something from scratch for the learning experience; if you just want something that works, why not just use something like Thor's particle system: http://www.bromeon.ch/libraries/thor/v2.0/tutorial-particles.html ?

I'm fully aware that there are way easier solutions, I use this to test my knowledge from the site: "This Simulator is an ongoing project, and is a tool to test my knowledge and understanding of OpenGL and SFML."

39
Edit 3:



Large update to the application, considered the first actual release for the project! There are a number of awesome new additions, check the changelog and give the program a try:

https://github.com/Syntaf/ParticleSimulator/releases

Or checkout the Github page and help contribute to the project!

https://github.com/Syntaf/ParticleSimulator

Edit 2:
A lot has changed since the last release!

Here's a short list of some of the changes from the latest release tab on the repo ;D:

  • Wrote a CMake build system! No more VS2012 clutter files
  • Experimental OpenCL support, thanks to finominis
  • Blending now uses GL_ONE, creating a range of awesome new particle colors
  • Fixed bug stopping events from being handled, not allowing people to quit
  • Code optimizations, big big speed improvements
  • Disabled depth testing, properly making texture alpha channels transparent
  • Drag increased by 1.5x
  • Particle count increased, specifically from 40,000 to 1,000,000 without any big performance loss
  • Window size increased but still maintains 1.33 ratio
  • Red Clamping value increased to turn make particles turn red at a lower speed

Edit 1:
Hi All,

I've been developing a particle simulation program using SFML and OpenGL for a couple months now, and recently finished a new physics system for calculating the next position of each particle. Problem is I didn't exactly implement it correctly, but I'm left with a pretty cool pulsating wave of pixels. The program now correctly simulates newtons second law of motion! Check it out at the repository here:
https://github.com/Syntaf/ParticleSimulator
The project is currently developed by myself and Finominis, but we are always looking for more people to contribute to the project!

or play around with the program using my pre-release
https://github.com/Syntaf/ParticleSimulator/releases/tag/v0.2-alpha

40
General discussions / Is there an SFML Mailing list?
« on: May 30, 2014, 04:15:02 pm »
I'm hoping to get a little more involved with SFML, and wondering if there is a mailing list for the repository? I don't think I'm quite at the level to start tacking the bug tracker, but would be willing to help with the easier stuff like documentation and any code that needs refactoring.

41
General discussions / Re: SFML 3 - What is your vision?
« on: May 30, 2014, 04:10:17 pm »
Some C++11/14 integration would be pretty cool to see in SFML  ;D. I've been a huge fan of the project since it's birth, and would love to be able to give a talk on SFML in the upcoming C++Now 2015 or Cppcon 2015

42
Window / Re: Map View Zoom
« on: May 30, 2014, 04:08:31 pm »
Post minimal code to your problem, if you want people to help you could at least spend the time to break down what chunks of code are relevant to the question and make it easier for everyone.

43
General / Re: Installation Problem
« on: May 30, 2014, 04:06:25 pm »
I wanted to install SFML to Dev C++. After reading many articles, I managed to compile the example program. It crashed.
Quote
AppName: test.exe    AppVer: 0.0.0.0    ModName: sfml-network-2.dll
ModVer: 0.0.0.0    Offset: 0000973a
After that I downloaded Code::Blocks and installed SFML 2.1. No compilation problems, just crash with message:
Quote
Instruction at 0×000 referenced memory at 0×000. The memory could not be read.
I searched google. Found solution with recompiling SFML. I recompiled it with no errors. I used recompiled files (dll, a) and compiled the program with no errors. Again the same crash while executing.
I have an old PC, Windows XP SP3. I did the same on my friend's new PC Windows Vista. Exactly the same result for Dev C++ and Code::Blocks. So I assume it's not the mashine nor the system problem.
I tried to install 2.0 and 1.6 too. Exactlz the same results.
I guess I am installing SFML the wrong way.

Please help.

Last I remember, Dev C++ is an extremely old IDE that hasn't been updated in a decade. I highly recommend jumping ship and learning an IDE that is continually supported such as Visual Studio or Code::blocks. These have a ton of community support as well as SFML support.

44
General / Re: Multithreading with sf::window
« on: May 25, 2014, 09:55:35 pm »
How did you imagine the waiting with threading? Did you assume threads would magically compute everything instantly? The hardware puts a limit on the parallelism that can be exploited by threads. Unless you have a huge distributed cluster, thousands of threads won't give you any benefit -- rather the opposite.

hmmm I worded that poorly, what I meant is before I shoved everything into a function I had a structure like this:

loop through all active particles on screen
        get mouse coordinates
        computer mouse coordinates in model space

        add force to particle proportional to mouse distance from particle
        add a drag force

        update new position of particle
        update color of particle based on speed
        update cameradistance

        fill position size data buffer with new coordinates
        fill color data buffer with new values
end loop

What I tried to do, and horribly failed at, was put all of that on a separate thread and launch it then wait for all of the results to compute after the loop ends. My thinking was launching x threads to compute y particles and waiting for the results to return after would be more efficient instead of synchronously doing each particle in the loop. Problem is if I only compute a certain part of the loop on a separate thread I need to wait for it to return before iterating to the next particle anyways. I see now I'll need to drastically change my program structure if I wanted to accomplish this

45
General / Re: Multithreading with sf::window
« on: May 25, 2014, 09:28:10 pm »
Have you even thought about the amount of synchronization you're going to need when threads share everything? Not only performance, but also correctness will be horrible to achieve.

You should really redesign everything, especially if you want to simulate a certain model. Otherwise you'll have to deal with a huge buggy mess...

You're very right, I'm not going to attempt that but probably look into using async for maybe only the math portion of the particle, and having say a future get the results before putting the data into the buffer? The only problem is if I have to wait for the results anyways why would I even use threading... I've come to a wall I can't seem to get around. I want to use parallelism for this program, it seems like it would be a great example, but I just can't figure out what I want to happen in the threads I launch.

Pages: 1 2 [3] 4 5 6