Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenGL rendering #250

Merged
merged 22 commits into from Jul 16, 2017
Merged

OpenGL rendering #250

merged 22 commits into from Jul 16, 2017

Conversation

wheybags
Copy link
Owner

@wheybags wheybags commented Feb 25, 2017

-librocket doesn't work, but I want to get rid of it anyway (probably for myGui + lua) Nuklear! https://github.com/vurtun/nuklear
-probably won't be merged until this is done

wheybags added 10 commits May 20, 2017
+ move font loading accordingly to FARender::Renderer
# Conflicts:
#	apps/freeablo/engine/enginemain.cpp
#	apps/freeablo/farender/renderer.cpp
#	apps/freeablo/farender/renderer.h
#	components/render/render.h
#	components/render/sdl2backend.cpp
Corruption would only occur if we attempted to setImmortal() a raw sprite
before we had ever rendered it.
get() in SpriteManager handles raw sprites with directInsert, but calling
setImmortal would skip straight to SpriteCache::setImmortal, which ensures
the sprite exists by calling get() and then setting the immortal flag.
However, since this was implemented inside SpriteCache, it wasn't handling
raw sprites, so it woul give an invalid sprite cache lookup error, and
corrupt the mUsedList member. The solution is to call get() in
SpriteManager::setImmortal before calling SpriteCache::SetImmortal, to
ensure that the raw sprite is created before we go into SpriteCache.
CMakeLists.txt Outdated
# Use C++11
if (CMAKE_VERSION VERSION_LESS "3.1")
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
set (CMAKE_CXX_FLAGS "--std=gnu++11 ${CMAKE_CXX_FLAGS}")
Copy link
Contributor

@Fuco1 Fuco1 Jul 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to use c++14? I've had it set locally ever since I've started working on this project and everything seems to work just fine.

Copy link
Owner Author

@wheybags wheybags Jul 15, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Travis is still using gcc 4.6.3, I'm not sure how much of c++14 is supported in that?

Copy link
Contributor

@Fuco1 Fuco1 Jul 15, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see. No big deal I guess, as far as I can tell we're not using any new features. But it's good to preemptively use newer standards if possible.

@wheybags wheybags force-pushed the opengl branch 2 times, most recently from 7a3f64b to 50b1dfd Compare Jul 15, 2017
@wheybags wheybags merged commit eb7e331 into master Jul 16, 2017
2 checks passed
@wheybags wheybags deleted the opengl branch Jul 16, 2017
@wheybags wheybags mentioned this pull request Jul 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants