Messages

1

Graphics / Re: playing with glad/gl.h : undefined symbol: sf_glad_glGetError

« on: June 12, 2024, 04:24:15 pm »

I was not aware of that fork, it helped me a lot ! Thank you

2

Graphics / playing with glad/gl.h : undefined symbol: sf_glad_glGetError

« on: June 10, 2024, 06:07:20 pm »

Hey, I am playing a bit with sfml and opengl to learn some stuff. I am trying to use opengl es 2 instead of 1.
I started by regenerating the glad header with the same extentions but with open gl es 2 in addition.
I saw that you added prefix sf_ before almost every symbols and I wondered why ? Was that necessary ?
Also I am getting a linker error on a lot of function pointers. The first one glad_glGetError (I removed "sf_"). I dont really understand as gl.h should be header only and I can't find a big difference with your file.
Can you help me with that ?
Thank you

3

Graphics / Re: Clarification from the sprite tutorial

« on: April 17, 2024, 09:25:01 pm »

Very clear thank you very much !

4

Graphics / Re: Clarification from the sprite tutorial

« on: April 13, 2024, 11:19:26 pm »

Hey, thank you for your reply !
Just a following question, is the 'cost' of that texture change related to the size of the texture ?
For example, would it be more efficient to :
- have a big single texture for multiple objects but alternately used with other small textures (Big texture -> Small Texture -> Big Texture -> Small texture)
- have many small textures and alternately called them (Small Texture -> Small Texture -> Small Texture -> Small Texture -> ...)

5

Graphics / Clarification from the sprite tutorial

« on: March 31, 2024, 06:50:16 pm »

Hello,
Currently reading the tutorial about sprites and textures
https://www.sfml-dev.org/tutorials/2.5/graphics-sprite.php#the-importance-of-using-as-few-textures-as-possible

Using as few textures as possible is a good strategy, and the reason is simple: Changing the current texture is an expensive operation for the graphics card. Drawing many sprites that use the same texture will yield the best performance.

As far as I understand, it is not `setTexture` method of `sf::Sprite` that in expensive, it is the fact of drawing a sprite with a texture, then a sprite with another one.
Am I right ?
Thank you

6

General / Re: Final answer for async loading texture ?

« on: March 27, 2024, 11:14:23 am »

Perfect ! Thank you

7

General / Final answer for async loading texture ?

« on: March 25, 2024, 10:20:49 pm »

Hey,
I want to load textures while my application is still running (logic + rendering).
I have been looking for a clear answer and the best I could find was in this topic some years ago :
https://en.sfml-dev.org/forums/index.php?topic=20569.0
It's said it's not recommended. Is it the same in 2024 ?
I don't know much about OpenGL, I have seen topics about internal/external context but not really a clear answer.
What are the best practices ?
Thank you

8

Graphics / 2 questions about VertexArray / VertexBuffer

« on: December 21, 2023, 11:13:40 am »

1. With Primitives Triangles, is there a way to specify all points then specify index of points used for each triangles ? Or the API just allows passing triangles directly by coords ?

2. With other than Triangles, is there a way to "reset" the primitive, for example with sf::TriangleFan, start a new TriangleFan in another location, but they will be drawn from the same VertexArray

Thank you

9

Graphics / few questions about VertexBuffer on Android

« on: December 06, 2023, 10:08:26 am »

I know PrimitiveType::Quad is deprecated with OpenGL ES, what about the others ? Is everything else ok on Android ?

How many vertices do you think an average phone can handle per draw call if I use sf::VertexBuffer(sf::Triangles, sf::VertexBuffer::Usage::Static); ? Is 100_000 still manageable ?

10

General discussions / When will shaders supported for android ?

« on: October 27, 2023, 02:25:46 pm »

Sorry I know there are several other topics about that but I can't find precise answer.
Just want to know if you are planning to rewrite stuff to handle shaders for android, I understood it's a lot a work and backward compatibility breaking so maybe for SFML 3. ?
Can I fork SFML and do it for my personal use ? Does it seems relatively doable (I mean, will it be faster to wait for you to do it)?
There is already this project https://github.com/TheMaverickProgrammer/SFML_ANDROID_ES_2 which is a fork of 2.5.1 and use gles2. If I fork from 2.6., will the work be different ?

11

General / Re: Android build error on launch

« on: August 16, 2023, 01:11:38 pm »

One of my custom file was using sf::Shader, unavailable on android with SFML.
Anyway now it's working, thank you

12

General / Android build error on launch

« on: August 15, 2023, 01:29:11 pm »

Hey,
I am trying to follow the guide with SFML 2.6 on android https://github.com/SFML/SFML/wiki/Tutorial:-Building-SFML-for-Android-on-Windows-with-Android-Studio
Build passed but on execution I have a fatal error :

Code: [Select]

2023-08-15 12:55:24.780 20653-20653 libEGL                  com.you.example.debug                E  validate_display:89 error 3001 (EGL_NOT_INITIALIZED)
2023-08-15 12:55:24.781 20653-20653 libc                    com.you.example.debug                A  C:\FactoryCapi\external_deps\SFML\src\SFML\System\Android\Activity.cpp:75: sf::priv::ActivityStates &sf::priv::getActivity(): assertion "states != NULL" failed
2023-08-15 12:55:24.781 20653-20653 libc                    com.you.example.debug                A  Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 20653 (u.example.debug), pid 20653 (u.example.debug)
I am using several libraries with SFML but I already made a simple project to check them and it was ok (launched as expected).
By simple project I mean a single main.cpp that calls some methods of each lib, so a very simple cmake.

But now I'm using my full source of my game with intermediate lib building and I have this error.
Just want to know if some of you already dealt with this, or have any idea about where the problem could come from.
The error occurred before the main is executed.

To give a little bit more information, here is my cmake lib dependency flow:
The example lib finally built relies on a custom lib FactoryCapi_flow

Code: [Select]

target_link_libraries(example PUBLIC
    FactoryCapi_flow
    log
    android
    sfml-graphics
    sfml-audio
    sfml-activity
    sfml-network
    -Wl,--whole-archive sfml-main -Wl,--no-whole-archive
    TGUI::TGUI
    TGUI::Activity
    EnTT::EnTT
    openal
    EGL
    GLESv1_CM
)
FactoryCapi_flow relies on FactoryCapi_core

Code: [Select]

target_link_libraries(
  FactoryCapi_flow PUBLIC
  FactoryCapi_core
)
FactoryCapi_core is built with those lib

Code: [Select]

target_link_libraries(
  FactoryCapi_core PUBLIC
  sfml-graphics
  sfml-system
  absl::flags
  absl::flags_parse
#  gRPC::grpc++_reflection
  gRPC::grpc++
  protobuf::libprotobuf
  quill::quill
)
In AndroidManifest.xml, I have

Code: [Select]

<meta-data android:name="android.app.lib_name" android:value="sfml-activity-d" />
<meta-data android:name="sfml.app.lib_name" android:value="tgui-activity-d" />
<meta-data android:name="tgui.app.lib_name" android:value="example" />
Thank you

13

Graphics / Re: Blur WITHOUT shader

« on: May 16, 2023, 04:05:30 pm »

Oh yes I didn't think about that !
Thank you for the little example I am going to try this 

14

Graphics / Re: Blur WITHOUT shader

« on: May 14, 2023, 08:14:00 pm »

Yes gaussian blur is the kind of result I would like, box blur could give also good result
Sorry to re-open the topic on the handle of shader with android, but can I wait for it or I really need to find another slotution with that ?

15

Graphics / Blur WITHOUT shader

« on: May 14, 2023, 04:11:54 pm »

Hello,
What is the best and efficient way to apply gaussian blur without shaders ? (because I want to play on android later)
Is drawing on RenderTexture and CPU compute blur the best way ? It seems too expensive to me
Thank you