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 - kojack

Pages: [1] 2 3 ... 17
I haven't tried running the code, but looking over it I'd guess the issue is how you are storing fonts.
When you set the font of a Text object, it stores it as a Font pointer. You load and store the font as part of your MenuBtn class.
Pushing temporary MenuBtn objects into a vector will result in the MenuBtn moving around in memory. But that breaks the Font pointer.

You'll need to make sure the Font doesn't move around.

(Also, it's not part of the crash, but loading a copy of a font for each button is inefficient. You only need one copy of the font then tell all Text objects to use the same one)

General / Re: Switch case behaving weirdly
« on: September 24, 2023, 06:44:41 am »
Technically only one case of the switch is running at a time, there's actually two events.

When you press a key like E, there's two events: a text entered event containing 101 or 69 (the unicode for "e" or "E" (depending on shift) and a key down event for the scan code 4 (the e key).
Not all keys generate textentered events, only ones with text equivalents. So not special keys.

This is how windows does it. Windows sends both a WM_CHAR and WM_KEYDOWN for keys like E, SFML turns them into Event::TextEntered and Event::KeyPressed.

Graphics / Re: Issue with converting Texture to Image
« on: September 18, 2023, 10:49:57 am »
If you have a texture:
Image img = tex.copyToTexture();

If you have a rendertexture:
Image img = rendtex.getTexture().copyToTexture();

Some actual numbers.
I built latest SFML 3 as both static and dynamic. Then I made a simple sfml test app that linked with graphics, system and window.

The exe is 12,288 bytes using dynamic sfml and 239,616 bytes using static sfml.

HOWEVER, the actual size for storage and distribution is 1,149,952 bytes for dynamic and 239,616 bytes for static. This is because dynamic sfml requires you to include 1,137,664 bytes of dlls in addition to the 12,288 byte exe. The static build doesn't need those extra files.

My Code can be in Debug or Release, and still target the Release build of SFML (and by extension, the Other Libraries) - it does not require a Debug build of CSFML to run, and running in Debug won't break the integration with the Release build of CSFML.

The key thing here is CSFML, it's not SFML.
Usually using a release library with debug applications is ok (a lot of binary only libraries do this). The main cause of problems is having C++ features like STL in the interface. Debug and release versions of classes like std::string and std::vector are different sizes (debug adds in some extra safety stuff), meaning a debug app calling a release library with an std::string as a parameter will pass incorrect data.

For example, std::string on Visual Studio 2022 is 40 bytes in debug builds and 32 bytes in release. An iterator is 24 bytes in debug and 8 bytes in release.

CSFML uses a C interface for the libraries, so there's no STL as parameters/returns.

General / Re: drawing Text array to screen crashes window.
« on: August 26, 2023, 06:23:36 am »
Sometimes it is, sometimes it isn't. (C and C++ love to confuse us) :)

Static and global ints default to 0. But local ints (like currentline) don't have a default (just what's in memory already).

General / Re: drawing Text array to screen crashes window.
« on: August 26, 2023, 04:18:59 am »
The problem will be this line:
int currentline;

In C++, if you don't assign a value to a variable, it's value will be whatever was already in memory, meaning it is effectively random. (In debug builds with visual studio, it will have a special value to represent it wasn't initialised).
So your for loop (the one that renders the text) might try to read a billion or more text objects instead of 4000.

Set currentline to 0 at the start.

General / Re: Can't create the sf::Drawable vector[error -1073741819]
« on: August 22, 2023, 01:16:56 pm »
I'm not sure what the other platform reply is about. But for the original problem, the issue in the first code is that the font is loaded and stored in a shared pointer. But Text objects don't understand shared pointers, they use normal pointers to store the font.
This means at the end of the createDrawableVector function, the font shared pointer only has 1 reference, so it deletes the font when the variable tahoma goes out of scope. But the Text objects in the vector still have normal pointers to where the font was.

You haven't said what went wrong or which compiler you are using, so its hard to say how to fix it.
First thing to check: you need to define SFML_STATIC in your project (or at least make sure its defined before including any sfml headers).

Next, at least on Visual Studio, you need to link with every dependency. For example sfml-graphics-s.lib requires you to link with opengl32.lib and freetype.lib too. Dynamic linking doesn't need that, the dlls include their dependencies already, but static linking works differently and needs then explicitly.
You can find a list of which libraries you need here: https://www.sfml-dev.org/tutorials/2.6/start-vc.php
I don't know about other platforms, I don't use SFML on them.

The way static and dynamic linking works on Windows (.lib and .dll files):
Static linking - a .lib file (static library) contains precompiled but unlinked code, basically an archive of .obj files. When you link with the .lib, the linker will add any required parts to the final .exe file. It doesn't add parts that aren't used by the .exe. You can now distribute the .exe on its own.

Dynamic linking - a .dll contains fully compiled and linked code. There is also a tiny .lib (import library) that contains just a list of what's exported by the dll. When you link with the .lib, code is added to the .exe to find and load the .dll at runtime and call the code in it. You distribute the .exe and the .dlls, not the .lib

A static link will actually give you a smaller distributed size, because only the parts of the libraries that are used will be added to the final .exe. A dynamic link will give a smaller .exe size, but the .dlls need to be there too and they contain everything, even if its never needed, so the total size is bigger.
Although if the .dlls are already on the user's system in a suitable location (there's certain locations that are checked), you don't need to distribute them. But then if the user doesn't have them, the program will crash.

(There's other stuff, this is just the basics)

General / Re: Im having trouble compiling SFML & ImGui
« on: August 08, 2023, 01:16:47 am »
You compiled main.cpp, but you also need to compile imgui.cpp, imgui_widgets.cpp, imgui_draw.cpp, imgui_tables.cpp and imgui-sfml.cpp then link all of the produced .o files with main.o.

General discussions / Re: When will you release SFML 2.6.0 officially?
« on: August 04, 2023, 11:08:58 am »
https://github.com/SFML/SFML/releases/tag/2.6.0bloxd io
No specific release date yet? I look forward to the new version too!
June 21 2023 was the specific release date, that link you quoted was the release. :)

General / Re: Static Linking
« on: July 11, 2023, 04:26:46 pm »
Have a look here for info on how to static link SFML: https://www.sfml-dev.org/faq.php#build-link-static
In particular, you need to define SFML_STATIC to change how all library functions are imported and you need to manually link with a bunch of libraries (that are automatic for dynamic linking) like opengl32 and freetype.

General discussions / Re: Mutual following on the Fediverse!
« on: July 04, 2023, 09:27:34 am »
I'm over at @kojack@mastodon.gamedev.place

Window / Re: Window won't display what I code
« on: June 18, 2023, 07:30:03 am »
If you are using Visual Studio, go into options page and check here:

If these are set wrong, then running a project won't rebuild the project automatically.
Usually VS will pop up a dialog when you try to run but there's an error, asking if you want to run the last working version instead. One option there is to run the old version and never ask again, which changes one of the settings in the picture above.

If you aren't using Visual Studio, it might be something like one of the files has a wrong timestamp so the build system thinks it is newer than the changed source.

Graphics / Re: Using sf::Text and sf::Font in Windows ×64 MinGW
« on: June 01, 2023, 03:25:58 am »
Space can be a factor too.
When a static library is linked, the linker can see which parts are being used, so it only merges those into your final executable.
When a dynamic library is linked, the linker doesn't know who will load it at runtime, so it must include everything.
This means a static link results in a slightly bigger executable than dynamic, but no dlls with unneeded stuff, so overall static will be smaller.

On the other hand, if you have several executables in your project (maybe a game, an editor, a config program, etc) that all use the same library, static linking means every one of them has to include the parts they need, while dynamic linking lets them all share the same dll. So dynamic might have a saving there.

Pages: [1] 2 3 ... 17