Resources > Coding
Game engine resources?
HylianGoombario:
Wow, I didn't know SFML had a .NET binding. Cool! That's worth considering instead of Monogame, which I'm currently using.
I gave up SFML with C++ for a couple reasons, almost a year ago when I started seriously doing game development. The thing that got me to quit was that I ran into this glitch that I just could not, for the life of me, find in the code. Someone told me that it might be lack of memory management and variables getting rewritten, or something. Idk. That frustrated me and made me quit. Another thing was that I couldn't find any way with SFML to see if a song had stopped playing, which I needed for syncing up the title screen properly.
As for your code: Yeah, you do seem to be really copying XNA, haha. I, personally, would take advantage of the simplicity that SFML offers. I would drop the GameCore class and the Program.cs file, and just use a simple int main() function to store all that stuff in. Not sure if this is good practice or not, but if you're cut loose from the ties of XNA, it'd be worth trying.
Cassyblanca:
--- Quote from: HylianGoombario on March 01, 2015, 06:48:26 am ---Someone told me that it might be lack of memory management and variables getting rewritten, or something. Idk. That frustrated me and made me quit.
--- End quote ---
I'm sorry, because I'm about to sound like a bit of a !@#$%. If learning how to manage memory is "frustrating" enough to make you quit, then maybe you should find something else to do because programming clearly isn't going to be a great choice.
--- Quote from: HylianGoombario on March 01, 2015, 06:48:26 am ---I, personally, would take advantage of the simplicity that SFML offers. I would drop the GameCore class and the Program.cs file tight butthole, and just use a simple int main() function to store all that stuff in. Not sure if this is good practice or not, but if you're cut loose from the ties of XNA, it'd be worth trying.
--- End quote ---
No, it is not a good practice. In fact, it's a very, very bad one. Properly structuring your code is one of the most important things you can do if you want to actually be able to complete a project any more complex than "Hello, World!".
If you actually want to learn to program, whether it's games, software, websites, whatever then you really should learn to do it properly. Otherwise, just use RPG Maker or some other tool that does everything for you.
HylianGoombario:
--- Quote from: Cassyblanca on March 01, 2015, 06:25:04 pm ---
--- Quote from: HylianGoombario on March 01, 2015, 06:48:26 am ---Someone told me that it might be lack of memory management and variables getting rewritten, or something. Idk. That frustrated me and made me quit.
--- End quote ---
I'm sorry, because I'm about to sound like a bit of a !@#$%. If learning how to manage memory is "frustrating" enough to make you quit, then maybe you should find something else to do because programming clearly isn't going to be a great choice.
--- End quote ---
The problem with it was, I don't even know how to do that. What could I have been doing wrong? I couldn't find any tutorials on it at the time either. Basically the way I saw it was, it's not working as I'm programming it and C# apparently doesn't require memory management, so I'd rather use that and it work.
--- Quote from: Cassyblanca on March 01, 2015, 06:25:04 pm ---
--- Quote from: HylianGoombario on March 01, 2015, 06:48:26 am ---I, personally, would take advantage of the simplicity that SFML offers. I would drop the GameCore class and the Program.cs file tight butthole, and just use a simple int main() function to store all that stuff in. Not sure if this is good practice or not, but if you're cut loose from the ties of XNA, it'd be worth trying.
--- End quote ---
No, it is not a good practice. In fact, it's a very, very bad one. Properly structuring your code is one of the most important things you can do if you want to actually be able to complete a project any more complex than "Hello, World!".
If you actually want to learn to program, whether it's games, software, websites, whatever then you really should learn to do it properly. Otherwise, just use RPG Maker or some other tool that does everything for you.
--- End quote ---
you're a bit of a fireball aren't you
I'm not talking about improperly structuring your code, I'm talking about taking the dozen or so lines of code from Update and maybe mingling them into the same function as the dozen or so lines of code from Draw, for the sake of simplicity, instead of making a Game class. If that's bad practice, then fine, but please don't talk to me like that
Cassyblanca:
--- Quote from: HylianGoombario on March 04, 2015, 06:19:00 am ---
--- Quote from: Cassyblanca on March 01, 2015, 06:25:04 pm ---...
--- End quote ---
The problem with it was, I don't even know how to do that. What could I have been doing wrong? I couldn't find any tutorials on it at the time either. Basically the way I saw it was, it's not working as I'm programming it and C# apparently doesn't require memory management, so I'd rather use that and it work.
--- End quote ---
Yes, C# does require memory management. While you aren't responsible for allocating, tracking and deallocating memory to the extent that you are in C, you still have to pay attention to the lifetime of your objects and be careful of how many and where you are allocating these. Garbage collector sweeps can be massive sources of performance problems in games.
--- Quote from: HylianGoombario on March 04, 2015, 06:19:00 am ---I'm not talking about improperly structuring your code, I'm talking about taking the dozen or so lines of code from Update and maybe mingling them into the same function as the dozen or so lines of code from Draw, for the sake of simplicity, instead of making a Game class.
--- End quote ---
I'm sorry but yes, you are talking about improperly structuring the code. Right now, sure, the methods are only "a dozen or so lines." But believe it or not, games take more than a "dozen or so lines" to update, and more than a "dozen or so lines" to perform rendering logic. And if the advice to "stick everything in main()" were followed, eventually the code would be an absolute mess. Encapsulating game logic into its own class is a good practice - the only thing that should go into main should be logic necessary to initialize and clean up the game/application.
--- Quote from: HylianGoombario on March 04, 2015, 06:19:00 am ---If that's bad practice, then fine, but please don't talk to me like that
--- End quote ---
If the advice you offer is bad, I'm going to call you on it. Because otherwise, somebody's going to see that advice and think "oh, I'll just throw everything in main! I don't need to consider the fact that my code is going to expand later and become a maintenance nightmare!"
HylianGoombario:
I said stick it in main because this is what my Update code looks like in my engine:
--- Code: --- protected override void Update(GameTime gameTime)
{
gamedata.input.Update();
gamedata.writer.Update(gamedata);
gamedata.cam.Update(gamedata.input.p_up, gamedata.input.p_left);
gamedata.screens[gamedata.current_screen].Update(gamedata);
base.Update(gameTime);
}
--- End code ---
and because this is what it looks like under draw:
--- Code: --- protected override void Draw(GameTime gameTime)
{
GraphicsDevice.Viewport = new Viewport(
0,
(graphics.PreferredBackBufferHeight / 2) - ((graphics.PreferredBackBufferWidth / (int)gamedata.resolution.X) * (int)gamedata.resolution.Y) / 2,
graphics.PreferredBackBufferWidth,
(graphics.PreferredBackBufferWidth / (int)gamedata.resolution.X) * (int)gamedata.resolution.Y
);
GraphicsDevice.Clear(Color.Black);
spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.NonPremultiplied, SamplerState.PointClamp, null, null, null, gamedata.cam.GetTransform() * Matrix.CreateScale(new Vector3((float)graphics.PreferredBackBufferWidth / gamedata.game_width, (float)graphics.PreferredBackBufferWidth / gamedata.game_width, 1.0f)));
gamedata.screens[gamedata.current_screen].Draw(spriteBatch, textures, gamedata);
gamedata.writer.Draw(spriteBatch, textures[7], new Vector2(0,0), gamedata);
base.Draw(gameTime);
}
--- End code ---
and it probably won't be changing a whole lot. If it does change, it'll be a line or two. GameData contains stuff like different screens, save data, camera, etc.
Personally, I don't think it'd be a crime if these things were side-by-side. That was my point. Not that you should badly structure code, but that creating a class just so you can have three functions didn't seem necessary to me.
---
About the memory management. Just like in the issue before, we're apparently talking about different things. I'm just saying that, when I used C++, a variable in my class was apparently being overwritten or something, somehow, causing very undesirable results. At least, that's what someone told me when I talked to them about it. I was quite new to C++ at the time, so the idea that my variable could just be overwritten willy-nilly in the memory because of something that was going on in the background that I didn't know about turned me off of it. Was this what was really happening? Idk. But I switched to C# because it was recommended to me, and I prefer it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version