@rockettiger Sorry about the PKGBUILD. I had copied from the other flare PKGBUILD and didn't change $_gitname. I've uploaded a fixed version to AUR (same link as before).
Maybe it would be a good idea to give Flare a launch flag that forces mods to only be loaded from ./
That way, we can make sure the Desura copy is looking in the right place. Plus, it'll be nice for devs and portable copies, as they won't acciendentally load data from an existing installation.
If you still want to attempt to get the Desura version working, you could try making a symbolic link at /usr/local/share/games/flare/mods/ that points to the flare mods folder inside your Desura folder.
I agree. I use an Atom-based netbook as my primary development machine for Flare, and it's nice to be able to test on the same machine as you compile :) I should give a special thanks to Stefan, who has done a lot in terms of optimizing so that we can run Flare on lower end systems.
I think SDL 2.0 might be our best bet if we want to support both OpenGL and our current method, but we'll see when the time comes.
I like how it looks, but it's very CPU intensive to draw 4 quarter-screen sized surfaces along with everything else (and that's just at 640x480). Plus, I haven't added a way to scale the images up to the screen resolution when they're loaded (could probably borrow from the SDL_gfx package for that). We *could* have a video option to enable/disable it if we really want to put this in the game. However, I think something like this would be better off in an OpenGL powered engine.
Lighting is something that has been discussed quite a bit amongst the devs. First, there's no "overlay" blending mode when we render each layer. So if you're trying to see how things might look in GIMP/Photoshop, use Normal blending mode and change the Opacity. Anyway, we tried to do something like this with another tile layer that contained semi-transparent dark tiles, but the drop-off wasn't soft enough, so it looked funny. I think our best bet for a lighting system will be if we move to SDL 2.0, which would probably let us easily use OpenGL (and thus have true dynamic lighting).
All that being said, the first two outdoor screenshots have a bit of a vignetting effect, which looks kind of neat IMHO. And I think it would be possible to do something like that on the current engine, and that it's worth experimenting with such an effect.
I think that when we design dungeons, we should keep in mind the total amount of possible loot the player can find on one run. They should be able to pick up every item without worrying if their inventory is full (assuming they enter the dungeon with a nearly empty inventory).
As Clint said, we'll use looping dungeons and the like to make it easy to return to town. Now, there are two reasons the player should want to return to a town:
To turn in quests for rewards
To possibly buy rare items from leveled merchants with random inventories
Neither of these cases mention the player selling items. But if we properly space the chances the player has to return to town, selling/stashing items during these visits will become second nature.
As for the question of "why do merchants want to buy my junk?", I think we can imagine they break down your old items to trade to people can make new ones. I believe Clint has even mentioned the possibility of letting the player themself do the break down -> craft task. No idea if that should actually be in a game like this, but its an interesting concept.
Make sure "Use Joystick" is unchecked in the in the Configuration menu (it's under the Input tab). When it's checked, the player always attacks in the direction they are facing (which is ideal for joypad controls).
../src/MenuStash.cpp needs to be added to CMakeLists.txt. I'm pushing the fix to my fork, but I haven't pushed in a while, so it's taking some time.
EDIT: That took longer than I expected. Apparently, we've merged in all of Flare's past commits, so the repository size has grown quite a bit. Anyways, everything should work now with the latest master.
@rockettiger
Sorry about the PKGBUILD. I had copied from the other flare PKGBUILD and didn't change $_gitname. I've uploaded a fixed version to AUR (same link as before).
Maybe it would be a good idea to give Flare a launch flag that forces mods to only be loaded from ./
That way, we can make sure the Desura copy is looking in the right place. Plus, it'll be nice for devs and portable copies, as they won't acciendentally load data from an existing installation.
I've opened an issue for this here: https://github.com/clintbellanger/flare-engine/issues/72
@Stefan
He shouldn't have to do all that, because I already know where the crash is happening. See this commit: https://github.com/dorkster/flare-engine/commit/cd7a9bcc2bd89be6faaa0905...
The AUR packages are outdated, but I've made one that downloads the 0.17 tag from the Github repo (via git, so it should be more reliable): https://aur.archlinux.org/packages.php?ID=63241
If you still want to attempt to get the Desura version working, you could try making a symbolic link at /usr/local/share/games/flare/mods/ that points to the flare mods folder inside your Desura folder.
@xmorg
I agree. I use an Atom-based netbook as my primary development machine for Flare, and it's nice to be able to test on the same machine as you compile :) I should give a special thanks to Stefan, who has done a lot in terms of optimizing so that we can run Flare on lower end systems.
I think SDL 2.0 might be our best bet if we want to support both OpenGL and our current method, but we'll see when the time comes.
Alright, so tried adding a vignette effect to the engine for fun: http://imgur.com/a/sfFno
I like how it looks, but it's very CPU intensive to draw 4 quarter-screen sized surfaces along with everything else (and that's just at 640x480). Plus, I haven't added a way to scale the images up to the screen resolution when they're loaded (could probably borrow from the SDL_gfx package for that). We *could* have a video option to enable/disable it if we really want to put this in the game. However, I think something like this would be better off in an OpenGL powered engine.
Lighting is something that has been discussed quite a bit amongst the devs. First, there's no "overlay" blending mode when we render each layer. So if you're trying to see how things might look in GIMP/Photoshop, use Normal blending mode and change the Opacity. Anyway, we tried to do something like this with another tile layer that contained semi-transparent dark tiles, but the drop-off wasn't soft enough, so it looked funny. I think our best bet for a lighting system will be if we move to SDL 2.0, which would probably let us easily use OpenGL (and thus have true dynamic lighting).
All that being said, the first two outdoor screenshots have a bit of a vignetting effect, which looks kind of neat IMHO. And I think it would be possible to do something like that on the current engine, and that it's worth experimenting with such an effect.
I think that when we design dungeons, we should keep in mind the total amount of possible loot the player can find on one run. They should be able to pick up every item without worrying if their inventory is full (assuming they enter the dungeon with a nearly empty inventory).
As Clint said, we'll use looping dungeons and the like to make it easy to return to town. Now, there are two reasons the player should want to return to a town:
Neither of these cases mention the player selling items. But if we properly space the chances the player has to return to town, selling/stashing items during these visits will become second nature.
As for the question of "why do merchants want to buy my junk?", I think we can imagine they break down your old items to trade to people can make new ones. I believe Clint has even mentioned the possibility of letting the player themself do the break down -> craft task. No idea if that should actually be in a game like this, but its an interesting concept.
Make sure "Use Joystick" is unchecked in the in the Configuration menu (it's under the Input tab). When it's checked, the player always attacks in the direction they are facing (which is ideal for joypad controls).
../src/MenuStash.cpp needs to be added to CMakeLists.txt. I'm pushing the fix to my fork, but I haven't pushed in a while, so it's taking some time.
EDIT: That took longer than I expected. Apparently, we've merged in all of Flare's past commits, so the repository size has grown quite a bit. Anyways, everything should work now with the latest master.
Pages