« first day (3487 days earlier)      last day (43 days later) » 

8:58 AM
@genaray heavy operations often don't need to be heavy. You can organize a system so it will use a quadtree or tile grid. They work better with position-related stuff, I mean, better than iterating all objects
however I don't know your current implementation, but I always try to optimize bottlenecks
the downside is that it slows down the development, so if you are making a prototype, just make it work
4 hours later…
1:08 PM
Hi again all. Quick update about my linker problems with box2d. I've found it is definitely not to do with the Linker settings (well at least I think it isn't). Thisis because I went into the b2World class code and added 'b2World() = default;' as a defaulkt constructor. Now, instead of the line b2World(gravity) in my noobEngine code, I just use b2World() and the program now builds successfully.
Still I'd like to figure out how to set it up without doing this because obviously it isn't the right way to do it
(was too tired after work last night to log in to mention this)
@Krangogram that's strange
but strange things do happen
yes it is. But actually although it builds, I cannot use the 'world' variable. eg. world.SetGravity(..) doesnt work :[
is world a variable?
probably is the 'linker' like u knowledable guys were saying yesterday
I think so. I have to set an instance of world no?
mayeb variable is wrong name, it is only initialiazed once I'd expect and then remains there throughout the game
When you say "doesn't work", you better specify how it doesn't work. What error do you have?
1:15 PM
@Krangogram Try to avoid "Doesn't work" in favor of "Doesn't compile/link because error message X".
Bleh, I'm slow.
this time when i say 'didnt work' what I mean is I declated b2World world (); /// ..ok fine . But the if I try below that for example: world.setGravity(0,-10); it now tells me setgravity is invalid. Also Intellisense finds nothing in 'world' (almost like its a class I made that is empty)
Look up "most vexing parse". b2World world (); is a declaration for a function called world that takes no arguments and returns a b2World. Compare with int f();.
however if I instantiate world the documented way ie: b2World world(gravity); Then i start to get Linker errors (but WIERDLY) then intellisense finds everything inside b2World and also no errors whilst I write stuff (but instead those Linker errors at buld time)
@nwp yes, I remember making that mistake once
ok thanks i will
i removed my default function i added into b2World (this is obviously not correct)

/// Construct a world object.
/// @param gravity the world gravity vector.
b2World(const b2Vec2& gravity);
thats the header for b2World (the official one)
1:20 PM
b2World world; // variable, default constructor called
b2World world (); // you have declared a function
Anyways, change it to b2World world(gravity); or b2World world;and then read the error message and which symbol it could not find. Then look up where the symbol was supposed to be found. Then link that source file or library.
to declare a default constructor in that class, would you put public: b2World() = default; ?
Ideally nothing. It gets auto-generated.
I've stripped this down to barebones. Its just a c++ console-app project with box2d. nothing else
#include <iostream>
#include <box2d/box2d.h>

int main()
std::cout << "Hello World!\n";
b2Vec2 gravity = b2Vec2(0.f, -10.f);
b2World world(gravity);

while (false)


1>------ Build started: Project: Box2d_TEST, Configuration: Debug Win32 ------
1>Box2d_TEST.obj : error LNK2019: unresolved external symbol "public: __thiscall b2World::b2World(struct b2Vec2 const &)" (??0b2World@@QAE@ABUb2Vec2@@@Z) referenced in function _main
1>Box2d_TEST.obj : error LNK2019: unresolved external symbol "public: __thiscall b2World::~b2World(void)" (??1b2World@@QAE@XZ) referenced in function _main
1>C:\_Dev_Tools\ExternalLibraries\Box2d\lib\box2d.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
> warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
1:23 PM
OOOH yeah
Looks like it doesn't find the Box2d code because you are trying to link the 64 bit library to your 32 bit project.
You're trying to link a .lib build for x64 with your project build for 32bit
Why do you have a 32 bit project?
last night late on i did get it Build i remember now
the most severe is the one about incompatible architecture
1:23 PM
but I have to target all my project to x4
I couldnt get Box2d to compiole as x86
I remember late last night I did a x64 empty project and used box2d, iit did work . I just forgot . How could I make a box2d.lib for x86 projects?
Why would you make a new project for an ancient architecture that is barely supported?
@Krangogram I would assume box2d has instructions for building on x86. I am however not familiar with them myself
well, my vs2019 defaults to x86. All the tuts I learnt from (prolly outdated) say x86 should be targetted unless you know otherwise, because ofc it can run on eitehr architecutes then
If you absolutely must support 20 year old computers then download or compile a 32 bit version, but eh, not worth it unless you get paid well to do it.
Elva, I have been looking for a while. Honestly I am not clever enough to read it all, but I kinda thought maybe they stopped doing 32bit. (Couldnt find anything stating that either tho)
1:27 PM
@nwp more like 6 years old I would think
If there is a 32 bit version of box2d, you need to use this one
but anyway
Many non-desktop devices probably use it?? I dunno
im still just learning tbh
i thought i was following good avise working in x86
hahah thanks tho guys and girls.... I can finally start the fun part again of just coding functionality into my little games :D
Oh, steam hardware survey says <1% of people use a 32 bit OS
if you really want x86 support you should download a library for x86
Nice NICE!!!!!
I will continue now on in x64
1:29 PM
(while steam hardware survey isn't representative for the general population it is representative for gamers)
but also for my own knowledge may try to find a 32bit box2d
> Windows 10 64 bit79.23%+7.58%
Windows 7 64 bit13.56%-7.52%
Windows 8.1 64 bit2.22%0.00%
Windows 70.68%-0.06%
Windows 8 64 bit0.16%-0.02%
Windows 100.15%-0.01%
(skipping a LONG way ahead of myself haha)
what about android games?
@Krangogram I don't play them. Don't support that platform.
Those, to my knowledge, aren't x86 or x64, they're ARM based
Or well, java
1:31 PM
me neither, just thinking really. And yes Elva you are correcto for sure!!
you people are the best ! thanks
x64 all the way then! :D
For now, don't worry about supporting everything. Just use 64 bit and don't worry
exactly, jeez i waste like 2+ days learning on that
then i forgot the answer and started scratching my head again until u helped me
lol i was there adding default constructors to b2World hahahahaha
A defaulted constructor most likely allowed the compiler to optimize everything out, resulting in no calls to box2d
1:39 PM
i think so yes. (some saying, about knowing a little is more dangerous than knowing nothing at all ) :D
I thought i knew what i was doing, end up in complete mess
I know a (very small) community named Noobs' advices. Members asked questions there and the more an answer was wrong, the more upvotes it received.
That sounds like fun.
Unless you want to learn something. Then it's terrible.
haha fun, but I would be the lead programmer there
@nwp yes it was
it's totally not a serious thing as you can guess
1:41 PM
I'm now going through my actual platformer game that the code I dessimated trying to fix this b2d crap. Wonder if I will ever get it working on x64... if not I will begin a fresh one today
honestly big love to all of you. i am gonna get my head down and try to actually achieve something here before I get off to work for the night again. Catch u all again soon!
Getting something running on x64 mainly just involves using the correct binaries
Unless you are Vaillancourt and have some weird stuff going on
2 hours later…
3:27 PM
loool , quick update. I found that my problem i think is SFML libs I had are 32bit and then box2d I can only seem to get x64. So there was no way I was getting it working with the libs I had. On SFML site , this is where I got the 'knowledge' that I should be working in 32 bit, because right at the top of their "Getting Started" page, it says I should probably start with 32bit even if I use 64 bit machine. sfml-dev.org/download/sfml/2.5.1
I am going to download the SFML 64 bit libraries and see if I can get my current game to work again, with box2d included. (Because, I can now run code with just box2d, or just SFML but not both
lol wow what a shitty take by SFML
I mean I guess what they are saying is true, since 32-bit works on both but 64-bit works "only" on 64-bit
@Krangogram My sympathies. Sucks to be stuck fighting with tools rather than working on your actual project challenges.
yeah for sure. i havve been struggling for a while :D
still am tbh , now in brand new project with box and sfml 64 it says "Code execution cannot proceed because sfml-graphics-d-2.dll was not found". The llink i specified is sfml-graphics-d.dll , i dunno where its getting the 2 from lol
i am attempting to google for answer now:D
dredded work lurking over me in 20 mins LOL
maybe its time i tried to focus my attention in Unreal Engine again ... :[ sad i wanted to learn to use lightweight frameworks, but honestly don't think im capable
3:47 PM
@Krangogram The DLLs have to be in the same folder as your executable.
ah ok. but afaik there is no such dll as "xxx -2.dll
and also should i manually paste them into where the debug exe is going ?
in my linker settings if I change "sfml-graphics-d.dll" to sfml-graphics-d-2.dll" (as per error message). I cant even build and it says "-2.dll" not found
Yes; when you build a project using external .dll, you need 3 things: the includes files for the compilation, you need the supplied .lib files for the linking, and then you need the .dll for the _execution.
ok. This newest error, i notice it does get as far as execution (first time I made it that far). The error for the -2.dll is an actual crash in the exe if you get what i mean
You don't supply dll names to the linker, you supply the .lib names, those that come with the .dll.
Inside 'Linker > Input' there is Additional Dependencies
I had to type "sfml-graphics-d.dll" etc
is that correct?
3:53 PM
No, it should also come with .lib files, you supply those .lib files to the linker, not the dll.
please check this from sfml site: sfml-dev.org/tutorials/2.5/start-vc.php
about half way down
the second Red Warning box of text in that tutorial
thats the image off their site
Yes, it says to write the .lib names, not the .dll names.
but it says add -d for debug
oh damn! sorry. I confirm in mine i have written 'lib
it was the erro for .dll that confused my typing sorry
The crash error in my app says .dll, my linker is correctly .lib
Ok, so you need to have same DLLs that match the .hpp files and the .lib files that came with the package you downloaded.
The .dll have to be copied to the same place, along with the .exe that is generated.
And, yes, all the debug stuff has to match, the .lib, the .dll and your exe.
Headers should be the same for both debug and release.
its wierd because right now im just doing empty project with only SFML. The ways im doing it worked perfectly with the 32bit sfml files i downloaded. I deleted those, downloaded the 64bit SFML files. Put them in similar location on my harddrive and done exact same Linker and Compiler Include Settings
I defintely only have the 64 bit SFML files on my system now
4:02 PM
Are the dll in the same folder?
i made a new folder C:_Dev_Tools\ExternalLibraries\x64\SFML-2.5.1\include
that has all the SFML hpp
i pointed vs2019 to that
i even tried opying SMFL hpp folder into where the debug exe of my project is
i do see that SFMl latest build was for VS2017
but i read somewhere its ok with VS2019. maybe it isn't
my next noob step is to download vs2017 haha
I think the linking would have failed if it didn't allow for using an older version.
coz i did the exact same thing with the 32bit files. Same folders nearly, and same linker settings. It worked fine. But the 64 bit one, maybe just isnt compatible for me?
sadly i have no understanding of why so its like shooting in the dark at this stage
How long have you been programming/working with c++?
Did you see this?
> The compiler versions have to match 100%!
a long time tbh. I started in the 90's but just as hobby and lost interest . But over the years I've prgrammed in many languages and I think i have an ok understanding of most coding concepts such as inheritence and polymorphism , etc etc. I can usually follow through c++ code and see how it all ticks
i think maybe i need to build my own SFML library from source?
if thats even possible. I will look when i get home again lol assuming im not too tired again haha
4:10 PM
@Krangogram Ok, cool :)
@Krangogram Yes, that was my next suggestion.
when i first started there was no one kind like you lot around. Back then id spend weeks on getting a IDE and libraries set up lol
I don't think I've ever worked with a library that required me to build it myself
yeah speak to ya soon. thanks again all
I did end up building SDL2 myself because I wanted to patch a bug, but that's it
Typpi. Id be very interested
4:11 PM
I don't know if you could just have it part of your project or if you need to build it separately.
if you had time... to build a x64 in vs2019 on windows 10
using files from their site
you want me to to setup a VS project with SFML on x64?
see if it is the files, or the if I am doing it wrong
just to see if its posisble using the files they offer on the website
hmm maybe I'll give that a go, I've got a few mins while my wings are in the oven
anyway im so sorry i really have to go ,. im late again lol
i will be back !!! :D
4:13 PM
@Tyyppi_77 Yeah, looks like sfml does not supply binaries for vs2019
Why are their binaries VS version specific? I don't remember there being an ABI break
Like I was able to switch all my projects from 2017 to 2019 without changing anything
That's what I though too...
@Krangogram Got it working easy, took me what, 7 minutes
With VS17 binaries
Looks like it should work too.
Maybe it's a configuration issue.
Most likely; I pointed the include directory to the correct place, linker path to the correct place, specified 4 libs required by their hello world, built the program, then copied the DLLs to the output directory
4:22 PM
Yep, "as simple" as that.
I did make the mistake of leaving the default x86 on
I don't understand why the default property settings aren't all targets & all platforms
That would be too convenient :P
Perhaps it's because it's creating less damage like that if you forget it at its default.
Yeah maybe; Also in a real scenario you do want different libs for debug/release, and for different architectures etc.
So maybe it's just the x86 that's the wrong default
From recent discussion, yes, it looks like it!
4:43 PM
Still fighting that impossible bug :/
I wonder if I'll level up once I'm done with it.
5:00 PM
do you at least have a consistent repro?
Semi consistent, yes.
working with physics engines is definitely very hard, I've only had to take a very brief look into PhyX and even that was pretty scary
Yeah. I have been able to add debug code in there to try and isolate the origin. At some point, two very small negative values are multiplied together, which seems to result in INF (??) and from that point on, shit is in the system and it crashes.
Have you tried with floating point exceptions?
Also holy fuck 0x00004's gravatar is a swastika
@Tyyppi_77 Hmm, not sure?
You mean the reduced size?
5:14 PM
@Krangogram, you dont even have to build box2d.lib. You can just add BOX2d folders to your project and thats it.
more obvious when its smaller yeah i.imgur.com/XF1rj68.png
@Vaillancourt something like this would throw when bad float values get made: stackoverflow.com/a/10895180/3450269
dunno if it helps though
@Tyyppi_77, that was default one
@Tyyppi_77 I dont think it will help me; in this case, "INF" is generated; I tried to enable the option in the settings and, well, I still get the same kind of behaviour (i.e. the "exception" from the library when I check for inf).
Ok, so yeah, super big values being multiplied together.
But I don't have a clue what those represent.
5 hours later…
10:06 PM
@Tyyppi_77 @Vaillancourt @0x00004 @ everyone else who helped me. I just got home and checked what the heck could i be doing wrong. I see now I have c++ compiler TDM-GCC32 installed. So I expect this is why the x64 isn't working. If this isn't the answer I almost give up. And 0x000 yes I have tried adding all the files directly to the project too, I tried several locations for them but can't get the correct place
no rush for any answer or anything, i was just updating with the situation.
Sounds unlike that VS would default to using some other compiler you have
yeah it made no difference lol
And what's the current error?
gonna try compile sfml from source, but i fear it won't work as you have comfirmed the SFML C++15 x64 files are ok on your system
10:19 PM
also gonna try VS2017
Yeah that's not gonna make a difference
darn lol
2017 is ABI compatible with 2019
so close to giving up, but it i really dont want it to get the better of me lol
Again, what's the current error?
10:20 PM
well , i dont get error inside visual studio now. I get crash style error
"xxx.exe System Error" the code execution cannot proceed because sfml-graphics-d-2.dll was not found
Should i drag SFML files to the output folder (i never understood that part yet)
'FRIDAY_FEELING.exe' (Win32): Loaded 'C:\Users\Main User\source\repos\FRIDAY_FEELING\x64\Debug\FRIDAY_FEELING.exe'. Symbols loaded.
'FRIDAY_FEELING.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'.
'FRIDAY_FEELING.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'.
'FRIDAY_FEELING.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'.
The thread 0x3328 has exited with code -1073741515 (0xc0000135).
The thread 0x24d4 has exited with code -1073741515 (0xc0000135).
The program '[25108] FRIDAY_FEELING.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
Have you copied the DLLs under x64/Debug?
in my new project?
well there you go
should i copy all SFML folder
with all the hpp inside?
no, the DLLs
10:23 PM
so the stuff from 'bin' folder from SFML storage location, copy the entire folder to be inside the x64/Debug .... lol i hope it is this simpl e:d
not the folder, just the contents
the DLLs should be next to your executable
In reality you only need the d-versions in debug & default versions for releases
wow ok i got it i think
there are so many similarly named folders, i'd tried this before but always chosen wrong fodler lol
So , am i to understand that ALL bins I use (for Box2d, SFml etc ) I always have to paste them here? Is this just because its debug? If I was on release now, would i have to manually copy the .bin files again?
Yes, release also needs the DLL files, this time under x64/Release
Wow ok , i was assuming by linking it all that these files could be copied automatically
Vaillancourt explained to you the difference between includes, linking and execution
10:27 PM
at least after all this i have learned a lot of my way around the Project Settings. Used to ignore these pages and now I kinda understand parts of it
And note that the DLLs must match with the libraries you link with, so if you link with debug libraries, you need debug DLLs and vice-versa (eventually you'll want to customize so that you don't suffer the debug performance penalties when shipping a release build)
....yeah i am seeing that I am slightly thick lol, i get mixed up between .lib and .dll on occasions. But im getting there gradually.
yeah i get that they have different configeration fro debug and release. Really appreciate your help there mate. I was just heading down a deeper and deeper rabbit hole

« first day (3487 days earlier)      last day (43 days later) »