Blade Brothers Engine: Creating my first 2D Game Engine

[LeonBlade]

REBIRTH

Hello everyone, it's been a long time.

http://www.youtube.com/watch?v=rcVeEFJk148

Please take note before watching, I'm redoing the way I handle Lua thanks to short and GyroVorbis as it appears I fucked up completely on how I'm going about this! So try not to facepalm to hard at my failures.

[GroundUpEngine]

Nice work man, good to see this project again! I like all the control used via Lua
But I also agree with Falco, don't let Lua do everything... find a balance!

Instead of std::vector or whatever, for the first entity indexed on the stack.

Code: Select all

Entity::EntityStack[0]...

Try std::map, with the first player on the stack. I use this from time to time..

Code: Select all

Entity::EntityStack["player1"]...

// So beforehand you can ->
Entity* ent = new Player();
Entity::EntityStack["player1"] = ent;

[LeonBlade]

Here is a link back to the question I posted earlier on Lua and C++ balance.
http://elysianshadows.com/phpBB3/viewto ... =13&t=6014

Again, thanks to short and GyroVorbis for putting me in the right direction as to how I should go about implementing Lua.
I'm pretty sure some of my Lua functions that are overloaded are in the right place, but the way I'm handling everything else is terribly terribly wrong.

I'll be creating a small little project (terminal based) for Lua and a dialog system so that I can get a better understanding as to what I need to be doing.

If you'd like to check out my Engine thus far, feel free to clone it like so:

Code: Select all

git clone git://github.com/LeonBlade/Blade-Brothers-Engine.git

Please be warned though, the Lua implementation again like I said is awful, and I'll be pushing changes to it later on in the day.
If you would like to help me tackle my Toolkit issues, that is in the git repo and I'm using Qt 4.7. Feel free to check it out, and let me know if you have any issues running it as the Run path needs to be set to the right spot otherwise it fails.

Nice work man, good to see this project again! I like all the control used via Lua

Instead of std::vector or whatever, for the first entity indexed on the stack.

Code: Select all

Entity::EntityStack[0]...

Try std::map, with the first player on the stack. I use this from time to time..

Code: Select all

Entity::EntityStack["player1"]...

// So beforehand you can ->
Entity* ent = new Player();
Entity::EntityStack["player1"] = ent;

Thanks a lot, man. It's projects like yours and others out there that motivated me back into working.
I'll be sorting out how I should go about that pretty soon, I have to do some revisions as to how I'm going about all this Lua nonsense.

[LeonBlade]

Changes are also pushed to the repo, not sure if everything will work out of the box, but it should work just fine.
Toolkit is in the stages of being remade, so it wont work what so ever, Engine should compile fine platform issues aside.
Still need to address the scrolling issue, but that will come later.

[bnpph]

To check if snapped to grid just use modulo, and split up movements into numbers divisible by grid number.

You are unable to move outside the map in some places because I'm assuming that you are accessing out of bounds data.

[LeonBlade]

To check if snapped to grid just use modulo, and split up movements into numbers divisible by grid number.

You are unable to move outside the map in some places because I'm assuming that you are accessing out of bounds data.

I already have grid snapping working just fine along with multiple other things like multiple tile selection etc.
The problem is the widget doesn't scroll and it offsets everything.

And the player being stopped by the map doesn't make any sense, there are no bounds of data in this case just a number telling where OpenGL needs to render a quad.

[bnpph]

I already have grid snapping working just fine along with multiple other things like multiple tile selection etc.

Oh, I guess I saw that from an outdated video - the new one looks good!

The problem is the widget doesn't scroll and it offsets everything.

Why not translate the GL matrix to match the scroll amount?

And the player being stopped by the map doesn't make any sense, there are no bounds of data in this case just a number telling where OpenGL needs to render a quad.

That's strange. Does it happen without the grid snapping code?

[LeonBlade]

I already have grid snapping working just fine along with multiple other things like multiple tile selection etc.

Oh, I guess I saw that from an outdated video - the new one looks good!

The problem is the widget doesn't scroll and it offsets everything.

Why not translate the GL matrix to match the scroll amount?

And the player being stopped by the map doesn't make any sense, there are no bounds of data in this case just a number telling where OpenGL needs to render a quad.

That's strange. Does it happen without the grid snapping code?

Ha, yeah it's fine man. I'm hoping to put the selection back in because I started from scratch AGAIN. It was really rough last time, so hopefully I can make it a lot better.

And yes! I think that's my problem... I just don't ever remember having to do it before, you know? So I was confused... hopefully I'll get that issue solved shortly. I'm adding just straight QGLWidgets to a QTabWidget so I need to change a few chunks of code to make the change work to add the QScrollArea back in.

And yeah, I'm not really sure why that happened... I haven't looked at it since then actually. I should put in the collision of the map edges anyways, I think I'll do that next.

Thanks for the reply by the way, very appreciated!

[THe Floating Brain]

Very nice work

[LeonBlade]

Very nice work

Thanks man!


Finally got auto-tiles working! Next will be making them work better and then start back on the Toolkit... again...

[MrDeathNote]

So are you calculating the autotiles every time they're rendered? Why not do your calculations and then edit the actual layer so that once you've edited it it'll persist. In fact you don't even need them in the engine at all, why not just have the calculations performed in the editor then just have your tile layout stored the same as normal. I might be missing something here since i'm in work and i'm trying to look productive while watching this

[XianForce]

So are you calculating the autotiles every time they're rendered? Why not do your calculations and then edit the actual layer so that once you've edited it it'll persist. In fact you don't even need them in the engine at all, why not just have the calculations performed in the editor then just have your tile layout stored the same as normal. I might be missing something here since i'm in work and i'm trying to look productive while watching this

Well, all the calculations can't be stored solely in the editor, because he's laying tiles in the actual engine, right? But editing the actual tile layer is definitely a good idea imo.

[Ginto8]

Well, one could actually have all the autotile calculations be done when you change tiles rather than when you render them. That would not only save CPU time, it would also make your life at least a little easier.

[bnpph]

Well, one could actually have all the autotile calculations be done when you change tiles rather than when you render them. That would not only save CPU time, it would also make your life at least a little easier.

Yeah, you only need to update the 8 adjacent tiles of the one that has been changed.

[MrDeathNote]

Well, one could actually have all the autotile calculations be done when you change tiles rather than when you render them. That would not only save CPU time, it would also make your life at least a little easier.

Isn't that what I said?

Well, all the calculations can't be stored solely in the editor, because he's laying tiles in the actual engine, right?

He's loading the file from the editor, if he's going to edit the layer he could do that in the editor. The visual effect would be the same in the engine since he would be loading the same data that he's calulating at runtime now. This is all assuming that he doesn't want to edit the level at runtime in the engine, if he does then I take back what I just said.