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

Pages: [1] 2 3 ... 228
1
SFML projects / Re: Screenshot Thread
« on: March 12, 2025, 06:23:07 pm »
I recently decided to push myself to see how much I could get out of my own knowledge of raw OpenGL (it's not much!) within SFML. Along the way, I factored it into a library and ended up arranging it so its use is very similar to SFML's graphics module.
Note that this is all done with SFML and only the OpenGL that is included by SFML's headers. No other external library (even any OpenGL) was included.





Here's a screen recording of the full test scene! ;)


Note that this "library" is just a personal test. It isn't being developed for public use; at least, not yet...
It also acts as a kind of "proof of concept" of what SFML 3D might have looked like.

2
Graphics / Re: Window to fill all screen and Texture transparent color
« on: March 12, 2025, 04:05:32 pm »
The size parameters for getLetterboxView are the actual width and height of the window. If your window is full-screen, these parameters should be the current resolution. Otherwise it should be the size of window in pixels.

sf::Vector2u windowSize{ window.getSize() }; // get the current size of the window
getLetterboxView(target, windowSize.x, windowSize.y) // use the window size here; the function sorts out the rest.

My guess as to how it would look in your code would be something like:
Vector2u windowSize = new Vector2u(Images.window.getSize()); // get the current size of the window
View target = new View(new Vector2f(200, 150), new Vector2f(400, 300));
Images.window.SetView(getLetterboxView(target, windowSize.x, windowSize.y); // use the window size here; the function sorts out the rest.

3
Graphics / Re: Window to fill all screen and Texture transparent color
« on: March 10, 2025, 09:57:51 pm »
We should clarify something here.

A window that is 400x300 will not fill the screen unless the screen's resolution is 400x300.
So, to fill the screen, we can change its resolution and go fullscreen with the window,
or we can make the size of the window the same size as the current resolution (this is commonly called "Windowed Fullscreen".)

The other thing to consider is that I expect you want to work with co-ordinates that go from (0, 0) to (399, 299) and to set that, you use a view.

So, first create a "target view" (the one you want to use within the window) like this:
sf::View targetView{};
targetView.setSize({ 400.f, 300.f });
targetView.setCenter({ 200.f, 150.f });
NOTE: I've set the size and center separately so it's clear what is happening but you can also set it in its constructor.

Then, set the window to use this target view:
window.setView(targetView);

Then, you can change the size of the window to match the full screen (or allow it to be resized).
The window will change size but the view will always be 400x300 so drawing at (200, 150) will always be in the centre.

You can just leave it there if you don't don't want the letterboxing effect and the window will always use the co-ordinates (0, 0) - (400, 300)-ish

But, since you do also want the letterboxing effect, you can use that function like this (whenever the window changes size, including when you set it or when it is resized):
window.setView(getLetterboxView(view, windowSize.x, windowSize.y));
windowSize is the actual current size of the window, and
view is the view we created earlier (it doesn't change)

This is obviously C++ code that I've used for the examples so you'll need to adapt to the version/language you're using.

4
Graphics / Re: I tried to build a particle system with VertexArray
« on: March 10, 2025, 06:39:04 pm »
The best option is pretty much always to draw them all together as a single vertex array. However, it's (a little bit) more complicated than just drawing lots of sprites.

Another option is to use some form of sprite batching. You can use a pre-made one or make your own.
I have two types already created:

https://github.com/SFML/SFML/wiki/Source%3A-Simple-Sprite-Batcher
takes a vector of pointers to already-created sprites and batches them into a single vertex array. This can be done every frame if required and should see an increase of speed to around 200% (or more!).
Here's a video example (warning: fast movement - flickering effects - may be unsuitable to watch):


https://github.com/Hapaxia/SelbaWard/wiki/Sprite-Batch
is a different approach. It itself contains the sprites and you update them via its interface (or copy a sf::Sprite). This way it can make internal optimisations so should result in better/faster results. This is a part of Selba Ward so feel free to have a look around for other things there you'd like to use too ;)

5
Window / Re: Integrating SFML with wxWidgets
« on: March 10, 2025, 06:23:28 pm »
Is this placing SFML inside wxWidgets? If so, is this issue only in Debug builds? How is it in Release builds?

6
Graphics / Re: Graphical glitch appearing
« on: March 03, 2025, 11:53:08 pm »
If you want to avoid the copying (mentioned above by eXpl0it3r), you could skip the "first sprite" temp and construct it directly in the vector since you already have a constructor ready:
sprites.emplace_back(default_texture);

7
I think my point about stress is it seems to be a "if you're slow, you progress slowly" as opposed to a "if you're slow, you'll fail until you're quick enough" type, which is more stressful so this would less so :)

Your bubbles look quite nice. I had presumed they were just static sprites; I had not realised that they were adjustable on the fly with your shaders. Nice work!

For me, though, overall, there seems to be too many "particles" (it seems "fussy"). But that's just me; I don't really play bullet hell games for this reason.

8
Just since this was brought up, I should mention that there are a couple of errors here and there in the documentation, whether it be not updated to 3 or may have been updated to 3 before it changed? I'll try to make a note of them when I spot them again.

Also, could we *please* have a dark theme for the documentation?

9
Nice. Looks cool!

Smart to involve your real-life cat too!

I'm guessing it's not a particularly stressful game?

Of course your cat is called "Byte"  ;D

10
Graphics / Re: No more default constructor for sf::Sprite?
« on: March 01, 2025, 03:37:52 pm »
The logic of having sf::Sprite without a texture doesn't make sense so this is probably the right approach. It's just the ability to pre-create sprites before attaching textures to them (often in large scales vectors). As there are alternatives (custom vertex arrays or just simply a rectangle), this could be just worked around.

However, things like sf::Sound are a bit harder to work around. Possible, but harder.

It's just a new workflow that we should get used to; again, I think it's the right approach.

My earlier suggestion is to help with porting code from stuff designed for SFML 2 (create a temporary, empty texture and create the sprites with that) but should not be the design going forward.

11
Haha; that's fantastic! ;D

12
SFML website / Re: Sticky menu hides linked content in the documentation
« on: February 26, 2025, 05:25:21 pm »
I noticed this too. Started getting used to automatically scrolling up. If you fix this, I'll be scrolling away from it! ;D

But do, please ;)

13
SFML projects / Re: SF::View or SF::RenderWindow?
« on: February 26, 2025, 05:24:06 pm »
You can also use "viewports" to separate a window into multiple areas but note that this can be confusing at first, especially if you're not very comfortable with views already.

Try this view tutorial if you'd like to understand a bit more about how they work:
https://github.com/SFML/SFML/wiki/Tutorial%3A-Using-View

14
SFML projects / Re: Selba Ward
« on: February 21, 2025, 06:44:13 am »
Update!

The Selba Ward wiki has now been updated to reflect the use of SFML 3.

This means that all of the wiki pages for each of the objects should now be up-to-date and all of the simple examples will run with SFML 3.

In addition, I've added a simple example for Pixel Display since it didn't have one.
That short, simple example generates an animation that I captured in a GIF:


15
SFML projects / Re: Selba Ward
« on: February 20, 2025, 08:16:08 am »
Quick Update!

Just a quick update to say that although Frame Transition has been available for some weeks/months now, it has had no documentation or examples. Now there are! I can understand that it might seem daunting at first (especially without documentation!) but hopefully the example can show just how simple it can be.

Here's the wiki page, explaining everything and included the code for the simple examples:
https://github.com/Hapaxia/SelbaWard/wiki/Frame-Transition

The 2 very short simple examples included on that wiki page create these transitions:
A wipe-style transition:

A push/slide-style transition:


And, here's a short video demonstrating multiple transition forms:


The code for the example that was used to create the above video is all here:
https://github.com/Hapaxia/SelbaWard/blob/master/examples/frameTransitionExample.cpp


The rest of Selba Ward's wiki is currently undergoing updates to match the SFML 3 versions now available.

Pages: [1] 2 3 ... 228