1
Graphics / Re: Drawing a subset of a vertex array?
« on: November 20, 2024, 03:04:29 pm »
Thanks!
But I'm using SFML.Net and it doesn't seem to have that in C#
But I'm using SFML.Net and it doesn't seem to have that in C#
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.
2
Graphics / Drawing a subset of a vertex array?
« on: November 19, 2024, 04:40:51 pm »
I have a particle system where sparks burn out over time.
Instead of creating a brand new VertexArray every frame with the burnt-out particles removed, I wanted to re-use the same VertexArray and just shift things around so that the burnt-out ones are on the end, and then not draw them by passing a count parameter to the Draw function. The idea is by not creating a new VertexArray every frame this should be much more performant.
But it seems the window.Draw function does not quite give me the overload I need.
renderWindow.Draw(vertexArray, 0, vertexCount, vertexArray.PrimitiveType);
This is invalid code because the first parameter needs to be an array of vertices instead of a vertexArray
but the VertexArray class does not expose its internal array of vertices. So any way I can do this?
Instead of creating a brand new VertexArray every frame with the burnt-out particles removed, I wanted to re-use the same VertexArray and just shift things around so that the burnt-out ones are on the end, and then not draw them by passing a count parameter to the Draw function. The idea is by not creating a new VertexArray every frame this should be much more performant.
But it seems the window.Draw function does not quite give me the overload I need.
renderWindow.Draw(vertexArray, 0, vertexCount, vertexArray.PrimitiveType);
This is invalid code because the first parameter needs to be an array of vertices instead of a vertexArray
but the VertexArray class does not expose its internal array of vertices. So any way I can do this?
3
Graphics / rotate tanslate vs translate rotate
« on: November 14, 2024, 07:18:17 am »
Back when I used to work in raw OpenGL, there was a difference between translating first then rotating, versus rotating first then translating.
In SFML, it seems that it doesnt matter what order you call SetOrigin, SetPosition, SetRotation
So how can I achieve the different behaviors (eg, rotate an object then move it to the right, versus move it to the right then rotate it)
Specifiaclly I an object to orbit my player at a distance, while always pointing toward him.
In SFML, it seems that it doesnt matter what order you call SetOrigin, SetPosition, SetRotation
So how can I achieve the different behaviors (eg, rotate an object then move it to the right, versus move it to the right then rotate it)
Specifiaclly I an object to orbit my player at a distance, while always pointing toward him.
4
Window / Custom cursor not working in title bar
« on: August 07, 2024, 03:41:38 am »
Working on polishing my app and one thing I never got working is the custom cursor in the title bar.
You know the bar at the top of the window with the app title and the minimize, maximize, close buttons? My custom cursor does not render when its in that area so you have to for example click close without seeing your cursor, just basically guessing where it is.
My custom cursor is simply a sprite that I move around every frame by setting it to the mouse location.
On program startup I call this
window.SetMouseCursorVisible(false);
Because I'm going to draw the custom one.
Whats the best practice here? Should I only call that if the cursor is NOT on the title bar? Seems kind of hacky but its the only thing I can think of.
You know the bar at the top of the window with the app title and the minimize, maximize, close buttons? My custom cursor does not render when its in that area so you have to for example click close without seeing your cursor, just basically guessing where it is.
My custom cursor is simply a sprite that I move around every frame by setting it to the mouse location.
On program startup I call this
window.SetMouseCursorVisible(false);
Because I'm going to draw the custom one.
Whats the best practice here? Should I only call that if the cursor is NOT on the title bar? Seems kind of hacky but its the only thing I can think of.
5
DotNet / Re: Can't used a joystick that is connected in the middle of program execution.
« on: June 05, 2024, 08:09:07 pm »
Thank you for the information.
Honestly I'm a bit confused why calling update manually keeps being proposed as a workaround. It does not work. Also I'm calling Joystick.Update() every frame anyway, so I wouldn't even call it a workaround, I would be completely happy with it.
Anyway I guess I'll keep an eye out for updates. Thanks!
Honestly I'm a bit confused why calling update manually keeps being proposed as a workaround. It does not work. Also I'm calling Joystick.Update() every frame anyway, so I wouldn't even call it a workaround, I would be completely happy with it.
Anyway I guess I'll keep an eye out for updates. Thanks!
6
DotNet / Re: Can't used a joystick that is connected in the middle of program execution.
« on: June 05, 2024, 05:12:39 pm »
Resurrecting this thread because I have the exact same issue and I don't see a solution yet.
Launching a game and then turning your controller on is an extremely common scenario so this bug is a big deal IMHO.
Every single time I'm having to restart the game because I forgot to turn on the controller first.
Launching a game and then turning your controller on is an extremely common scenario so this bug is a big deal IMHO.
Every single time I'm having to restart the game because I forgot to turn on the controller first.
7
Graphics / Re: How to draw object with position relative to another object?
« on: May 29, 2024, 05:47:50 pm »
Yup I think I have something relatively clean now.
I must have been thinking back to using raw OpenGL, when you could use Push() and Pop() to save and load transformation states, and could get the same effect without having to pass any objects around.
I must have been thinking back to using raw OpenGL, when you could use Push() and Pop() to save and load transformation states, and could get the same effect without having to pass any objects around.
8
Graphics / Re: How to draw object with position relative to another object?
« on: May 27, 2024, 05:35:58 am »
Thanks for this!
Its better than what I had for sure.
I made a small improvement by moving the hitpoint object into the player which makes more sense to me.
Unfortunately something still seems a bit inelegant about it, specifically having to pass the new RenderStates() thing to the draw call. But I guess there is no way to make this implicit.
Anyway thanks again!
Its better than what I had for sure.
I made a small improvement by moving the hitpoint object into the player which makes more sense to me.
Unfortunately something still seems a bit inelegant about it, specifically having to pass the new RenderStates() thing to the draw call. But I guess there is no way to make this implicit.
Anyway thanks again!
9
Graphics / How to draw object with position relative to another object?
« on: May 24, 2024, 10:53:43 pm »
I'm always solving this problem in a dumb way and I know theres a better way.
Suppose I have a Player class, and also a HitPoint class.
The Player object contains an instance of a HitPoint object.
When I draw the player, I also want to draw the hitpoint bar near his head.
So what I end up doing is in the Player's render method, I pass the player's relative position to the HitPoint's render method. So that I can draw the hitpoint bar at the same location of the player, but 50 pixels higher and 10 to the left.
What I'd like to avoid is somehow having to pass positions around like that. It seems like my render code is FULL of ugly little offset maths like xPos + xPos2 + 35.
Example of the problem:
So for example I'd prefer to have the HitPoint Render method look more like this
So I'm drwaring the hitpoint bar from (0,0) and not worrying about the Player's position. Something else will "move" the hitpoint bar to the right place.
Suppose I have a Player class, and also a HitPoint class.
The Player object contains an instance of a HitPoint object.
When I draw the player, I also want to draw the hitpoint bar near his head.
So what I end up doing is in the Player's render method, I pass the player's relative position to the HitPoint's render method. So that I can draw the hitpoint bar at the same location of the player, but 50 pixels higher and 10 to the left.
What I'd like to avoid is somehow having to pass positions around like that. It seems like my render code is FULL of ugly little offset maths like xPos + xPos2 + 35.
Example of the problem:
class Player {
int xPos;
int yPos;
HitPoint hpBar;
public void Render() {
DrawThePlayer();
hpBar.Render(xPos, yPos);
}
}
class HitPoint{
public void Render(int x, int y) {
DrawRect(x-10, y-50....
}
}
int xPos;
int yPos;
HitPoint hpBar;
public void Render() {
DrawThePlayer();
hpBar.Render(xPos, yPos);
}
}
class HitPoint{
public void Render(int x, int y) {
DrawRect(x-10, y-50....
}
}
So for example I'd prefer to have the HitPoint Render method look more like this
class HitPoint{
public void Render() {
DrawRect(0, 0)
}
}
public void Render() {
DrawRect(0, 0)
}
}
So I'm drwaring the hitpoint bar from (0,0) and not worrying about the Player's position. Something else will "move" the hitpoint bar to the right place.
10
Graphics / Re: View, Viewports and getting mouse location
« on: December 06, 2023, 06:56:53 pm »
I must be missing something.
From what I see, you can't convert screen coords to world coords until you set the View to a Window/RenderTarget. So I actually have to do graphics work in my Update function. Something like this:
Update Method:
Render Method:
And I don't see how I can avoid adjusting the view in the Render phase because the Update phase has left it in the wrong view state.
On top of it, the Update method is actually called several times for every Render method (accurate physics sometimes requires this), so it ends up being a lot of view switching. Hopefully its fast at least.
From what I see, you can't convert screen coords to world coords until you set the View to a Window/RenderTarget. So I actually have to do graphics work in my Update function. Something like this:
Update Method:
RenderWindow.SetView(new View( .. world view / viewport details) );
Vector2i mousecoordsWorld = RenderWindow.MapPixelToCoords(getMouseCoords());
// do world updates such as shoot bullets
RenderWindow.SetView(new View( .. HUD view / viewport details) );
Vector2i mousecoordsHud = RenderWindow.MapPixelToCoords(getMouseCoords());
// do hud updates such as updating button states and detecting clicks...
Vector2i mousecoordsWorld = RenderWindow.MapPixelToCoords(getMouseCoords());
// do world updates such as shoot bullets
RenderWindow.SetView(new View( .. HUD view / viewport details) );
Vector2i mousecoordsHud = RenderWindow.MapPixelToCoords(getMouseCoords());
// do hud updates such as updating button states and detecting clicks...
Render Method:
RenderWindow.SetView(new View( .. world view / viewport details) );
// render world
RenderWindow.SetView(new View( .. HUD view / viewport details) );
// render Hud
// render world
RenderWindow.SetView(new View( .. HUD view / viewport details) );
// render Hud
And I don't see how I can avoid adjusting the view in the Render phase because the Update phase has left it in the wrong view state.
On top of it, the Update method is actually called several times for every Render method (accurate physics sometimes requires this), so it ends up being a lot of view switching. Hopefully its fast at least.
11
Graphics / Re: View, Viewports and getting mouse location
« on: December 05, 2023, 02:49:59 pm »
Thanks!
I'm doing that now - the input mouse coordinates are globally accessible in the player object.
No problem adjusting the views based on these coordinates and even calling MapPixelToCoords() a few times during Render, to make the right things happen visually.
The issue is when I want to actually do something, like fire a bullet, which is definitely Update and not Render logic. But I cannot fire the bullet until I'm halfway through the Render function because this is when I've got the right view set up for calling MapPixelToCoords() and actually firing the bullet in the proper direction ad the proper angle.
Editing to give an example
During the Update() method, I grab the mouse coords. Lets say its 243, 150. This is global state accessible from anywhere no problem so far.
Mouse button is clicked, so, still in the Update method, I fire a bullet toward 243,150 coordinates.
Rest of Update method completes.
Now Render method starts
Change View/Viewport to render the Hud. Now that same mouse coord maps to -543, 280 world coordintes.
Change View/Viewport to render the game area. Now that same mouse coord maps to 20943,10080 world coordintes. I should have fired the bullet towards 20943,10080 but could not have known that until this point in the Render method!
I'm doing that now - the input mouse coordinates are globally accessible in the player object.
No problem adjusting the views based on these coordinates and even calling MapPixelToCoords() a few times during Render, to make the right things happen visually.
The issue is when I want to actually do something, like fire a bullet, which is definitely Update and not Render logic. But I cannot fire the bullet until I'm halfway through the Render function because this is when I've got the right view set up for calling MapPixelToCoords() and actually firing the bullet in the proper direction ad the proper angle.
Editing to give an example
During the Update() method, I grab the mouse coords. Lets say its 243, 150. This is global state accessible from anywhere no problem so far.
Mouse button is clicked, so, still in the Update method, I fire a bullet toward 243,150 coordinates.
Rest of Update method completes.
Now Render method starts
Change View/Viewport to render the Hud. Now that same mouse coord maps to -543, 280 world coordintes.
Change View/Viewport to render the game area. Now that same mouse coord maps to 20943,10080 world coordintes. I should have fired the bullet towards 20943,10080 but could not have known that until this point in the Render method!
12
Graphics / View, Viewports and getting mouse location
« on: December 05, 2023, 07:17:13 am »
The common recommendation for making games is to have separate Update() and Render() methods.
In Update(), I get all inputs (including mouse x y coordinates) and do all updates.
Problem is in the Render() method, I end up changing the view/viewport a few times because there is a HUD and game area at least. It means that the mouse coordinates (specifically the world mapped version of them) I grabbed in the Update() function are not correct by the time the Render() function changes the view stuff around.
So now it seems like I'm forced to put some of my Update() code inside the Render() function because this is where I will finally have the right inputs.
I really don't want to mix the update and the render logic like this though. What am I missing?
In Update(), I get all inputs (including mouse x y coordinates) and do all updates.
Problem is in the Render() method, I end up changing the view/viewport a few times because there is a HUD and game area at least. It means that the mouse coordinates (specifically the world mapped version of them) I grabbed in the Update() function are not correct by the time the Render() function changes the view stuff around.
So now it seems like I'm forced to put some of my Update() code inside the Render() function because this is where I will finally have the right inputs.
I really don't want to mix the update and the render logic like this though. What am I missing?
13
Graphics / Re: Best practices for sprites?
« on: November 21, 2023, 06:04:43 pm »
Your understanding of the code is correct. There is no behind the scenes copying of objects or anything that would be hiding a big performance impact.
I also wonder if there is any texture switching going on. But there absolutely shouldn't be because there is only 1 texture in the entire app, and every sprite references it when it is created, and it never changes.
I'm drawing 20,000 sprites. Release mode, but Debug mode is the same (slightly slower but still a big relative difference between the 2 approaches)
I also wonder if there is any texture switching going on. But there absolutely shouldn't be because there is only 1 texture in the entire app, and every sprite references it when it is created, and it never changes.
I'm drawing 20,000 sprites. Release mode, but Debug mode is the same (slightly slower but still a big relative difference between the 2 approaches)
14
Graphics / Re: Best practices for sprites?
« on: November 20, 2023, 10:34:13 pm »
Yea, I'm hearing you guys that vertex arrays are the way to go. I think I tried them long ago, and I forget what but something about them didnt quite work for my scenario. I'll look again.
But as a programmer, I still want to understand whats going on with the sprites.
with pseudocode, here are the 2 scenarios boiled down:
#1:
#2:
#2 has much less setting of variables and creation of unnecessary new objects. The only downside I can see for #2 is more memory usage (and its hardly any). Its the same number of draw calls either way. But #2 is way slower.
But as a programmer, I still want to understand whats going on with the sprites.
with pseudocode, here are the 2 scenarios boiled down:
#1:
foreach (var baddie in baddies) {
theOnlySprite.x = baddie.x;
theOnlySprite.y = baddie.y;
theOnlySprite.color = baddie.color;
theOnlySprite.rotation = baddie.rotation;
theOnlySprite.scale = baddie.scale;
window.Draw(theOnlySprite);
}
theOnlySprite.x = baddie.x;
theOnlySprite.y = baddie.y;
theOnlySprite.color = baddie.color;
theOnlySprite.rotation = baddie.rotation;
theOnlySprite.scale = baddie.scale;
window.Draw(theOnlySprite);
}
#2:
foreach (var baddie in baddies)
{
window.Draw(baddie.mySprite);
}
{
window.Draw(baddie.mySprite);
}
#2 has much less setting of variables and creation of unnecessary new objects. The only downside I can see for #2 is more memory usage (and its hardly any). Its the same number of draw calls either way. But #2 is way slower.
15
Window / Re: Joystick doesn't work unless its connected before program starts
« on: November 20, 2023, 03:34:06 pm »
Yes I am!
Thanks I'll look at these links and see if it can help me (or if I can help out).
Thanks I'll look at these links and see if it can help me (or if I can help out).