Game Development

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

@nwp

ok thanks i will

i removed my default function i added into b2World (this is obviously not correct)

public:

/// 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.

ok

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

YOU ARE RIGHT

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%

store.steampowered.com/hwsurvey/…

(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

noob

user92578

A defaulted constructor most likely allowed the compiler to optimize everything out, resulting in no calls to box2d

1:39 PM

:thinking:

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!

user92578

Getting something running on x64 mainly just involves using the correct binaries

user92578

Unless you are Vaillancourt and have some weird stuff going on

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

user92578

lol wow what a shitty take by SFML

user92578

I mean I guess what they are saying is true, since 32-bit works on both but 64-bit works "only" on 64-bit

Pikalek

@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

files

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

user92578

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

user92578

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

user92578

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

user92578

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

Later!

@Tyyppi_77 Yeah, looks like sfml does not supply binaries for vs2019

user92578

Why are their binaries VS version specific? I don't remember there being an ABI break

user92578

Like I was able to switch all my projects from 2017 to 2019 without changing anything

That's what I though too...

user92578

@Krangogram Got it working easy, took me what, 7 minutes

user92578

With VS17 binaries

4:21 PM

Looks like it should work too.

Maybe it's a configuration issue.

user92578

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

Yep, "as simple" as that.

user92578

I did make the mistake of leaving the default x86 on

user92578

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.

user92578

4:26 PM

Yeah maybe; Also in a real scenario you do want different libs for debug/release, and for different architectures etc.

user92578

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.

user92578

5:00 PM

do you at least have a consistent repro?

Semi consistent, yes.

user92578

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.

user92578

Have you tried with floating point exceptions?

user92578

Also holy fuck 0x00004's gravatar is a swastika

5:11 PM

@Tyyppi_77 Hmm, not sure?

@Tyyppi_77 gravatar.com/avatar/…

You mean the reduced size?

0x00004

@Krangogram, you dont even have to build box2d.lib. You can just add BOX2d folders to your project and thats it.

user92578

more obvious when its smaller yeah i.imgur.com/XF1rj68.png

user92578

@Vaillancourt something like this would throw when bad float values get made: stackoverflow.com/a/10895180/3450269

user92578

dunno if it helps though

0x00004

@Tyyppi_77, that was default one

5:18 PM

@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.

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.

user92578

Sounds unlike that VS would default to using some other compiler you have

yeah it made no difference lol

user92578

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

user92578

MSVC17*

10:19 PM

also gonna try VS2017

user92578

Yeah that's not gonna make a difference

darn lol

user92578

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

user92578

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'.

user92578

Have you copied the DLLs under x64/Debug?

in my new project?

no

user92578

well there you go

should i copy all SFML folder

with all the hpp inside?

user92578

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

user92578

not the folder, just the contents

user92578

the DLLs should be next to your executable

user92578

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?

user92578

Yes, release also needs the DLL files, this time under x64/Release

10:27 PM

Wow ok , i was assuming by linking it all that these files could be copied automatically

user92578

Vaillancourt explained to you the difference between includes, linking and execution

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

user92578

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)