So I setup a skybox in OpenGL using a cubemap. Then I did environment reflections using a cubemap.
Now my skybox is the environment map from one of the objects in the scene.
https://files.facepunch.com/forum/upload/133270/d25a0d7d-4325-4b25-a61f-7f789a9269f6/image.png
And it's moving.
Took em long enough
It's just that gamedev stuff tends to have flashy visuals. With the exception of paindoc's space industry blog, I don't tend to like reading posts with lots of code in them. Show us what you made, not how you made I guess. Of course, this is just how I browse. I don't know about anybody else.
For what it's worth, I really prefer the long write-ups and non-gaming stuff nowadays. There's only so many times I can be impressed by "I got OpenGL to work!". I just don't really engage with the posts I find interesting, I just read them and move on. It's a thankless job for content posters but somebody's gotta do it.
I made a cool little visualization thing. I thought it would look cool while tripping.
[vid]http://wyattmarks.com/screenshots/visualizations.mp4[/vid]
Confront him about that. Shit behaviour like this only creates work for everyone else who has to deal with his shit. I wouldn't hesitate to reject a commit like that.
I've been slowly sinking into the quicksand/black hole that is WS-Management, as I'm writing a BMC smart-proxy for controlling Intel AMT clients.
Functionality-wise it's really amazing how much system control you can get out of a regular desktop CPU compared to a separate IPMI SoC, but ease-of-use certainly wasn't their goal for any of this.
Sheesh, I just started a medium-sized fight between two coworkers because I asked if I could have a Jira account
I got it btw
I never realized how much I took debuggers for granted until I had to write in ARMv8 assembly for class assignments.
Access a bad memory address? Program simply prints "Segmentation fault" and kills itself.
Been working on this game for about 6 months now, it's called Asteroid Quest.
It's basically a chilled out and scaled down space exploration and mining game, for iOS and Android.
I'm shooting to have it finished by the end of May, but we'll see how that goes.
Anyway, here's a short video showing off a small feature I finished today:
https://files.facepunch.com/forum/upload/132887/d578b198-cdff-4c0e-b38b-b26244dec615/2018-03-22_12-45-59.mp4
My flight software work has been a fucking nightmare of this shit
I've tried again and again, but he just doesn't really care. Good news: I'm back off that trainwreck of a project.
And back into that NBody sim that has caused my saltiest posts here. Yayyyyyyy?
(actually, better the devil I know tbh)
It's great, I see literally no downside. Only a slight difference in the way the code is written, but you get to write less since no safetying the changing of states, plus in some instances you don't have to write some redundant target identifiers, plus it runs faster.
Thank god for find & replace , I had a lot of code to update
DSA translates well into RAII, unlike the old system, just an fyi. Don't go overboard but it's pretty nice tbh.
Trying my hand at triple buffered persistently mapped buffers.
https://files.facepunch.com/forum/upload/582/e0b5edc9-7ac0-4b00-b706-1d18bb48fc4f/image.png
Truly a next gen experience
well the obvious downside is that you lose support for systems that don't support opengl 4.5 or GL_ARB_direct_state_access and GL_ARB_separate_shader_objects, which e.g. macOS doesn't
Sometimes you have nothing to do at work. So I investigated the Custom Editor Windows of Unity.
https://github.com/mathiassiig/unity-debugging-visualization-example
https://github.com/mathiassiig/unity-debugging-visualization-example/raw/master/example.png
It's kind of nice if you want some tool that shows things in a different way than the default inspector does. It's not too horrible to use, but it does make me wish you could do the design like you do with the UI for the actual games. Doing it all from scripts is not really that awesome to maintain, and you'll just end up with ugly magic numbers in your code no matter what. Regardless, I will be using this to debug AI agents in my game.
That lack of support being mostly because Apple is trying to enforce usage of Metal.
What, why do that? Triple buffered how? I'm thinking of how I split up resources into shared and per-swapchain image in Vulkan and I can't think of any reason I'd do this. I'm not going to be of much help though, cus mapping of memory and such is one of the areas Vulkan is even more removed from OpenGL
I've been working a bit on getting a rather neat library to support CMakeLists: https://github.com/t0rakka/mango
The guy working on it is really friendly and enthused, and the CMake support should be mostly working now. The library itself seems rad, and I'm probably going to be using it to replace my mashup of gli + glm + stb. In particular, being able to memory-map files and easily access zipped files + handle various compressed image formats (and write various image formats) is just too nice to turn down.
Otherwise being back on the N-body sim is interesting - this time I'll be working with a major aerospace company so that's a bit frightening. I'm trying to get a visualization demo working by next Wednesday.
I've heard that several times over that allocating 3x the size and using it as a ring buffer is the "best" way if updating the data every frame.
My previous implementation would just check a sync fence, update the data, and then place another sync fence, but there was an issue with the camera data streaming incorrectly, probably because it getting read/written to at the same time.
However my solution didn't help anyway :shrug:
My company lets me keep all my inventions so long as I dont use their time or resources. Office hours are 9-6 though
The set of unity videos by this guy is pretty cool how he incorporated so much into unity.
https://www.youtube.com/watch?v=9bHzTDIJX_Q
This is a decent way of doing it yeah, just writing to subregions depending on the current frame and but it would still require (at least in Vulkan) a memory barrier in the drawing section to avoid drawing while the host is writing. these barriers can also have an offset specified - only causing the barrier for that region. Is this possible in OpenGL?
I'd check your alignments, offsets for mapping/writing, and so on as this looks like super corrupted data. It should be performant and fairly possible though.
Are you writing an extractor for any particular game? I've managed to get something working for Counter-Strike Xbox .xpr files but the width and height are actually in ResourceFormatData, ResourceSizeData seems to always be 0 and D3DFormatType contains values 12 or 15 (and maybe 14) which don't correspond to anything in D3DFORMAT (but are DXT1, DXT4 and 14 is DXT3).
there's glMemoryBarrier in OpenGL but if the buffer is created with the COHERENT flag this is handled automatically for you
Coherent should probably just mean you don't have to call "glFlushMappedBufferRange" for the changes to be visible to the device, but might still require memory barriers? idk
the docs for glBufferStorage explicitly say that glMemoryBarrier isn't necessary when GL_MAP_COHERENT_BIT is specified, unless i'm reading it wrong
Working on a vtable table dumper
oh wow Garry made the forums great again cool
I've been outgrowing love2d over the years and I can't be bothered learn another engine and have it blow up in my face like 2004/2007/2013 source
unreal and unity are too big for me, and love2d is too small
developing your own game framework looks like this:
choose the language you like the most and are most productive in, then package together sdl, opengl, kazmath, physicsfs, devil, freetype, sdl_sound, openal, chipmunk, assimp, gltf 2.0 pbr reference shaders, cef, enet, opus, and your language of choice's multithreading (or fallback to sdl), and some networking library with https support, then give it some shit name like lgf https://github.com/Planimeter/lgf
if you want to consume less disk space and are willing to sacrifice features, use stb headers instead
if you're okay with using c++, switch out some of the c libraries above with the flavor of your choosing, like adding bullet for 3d physics instead of just 2d with box2d or chipmunk
if you want to support vr, drop in openvr, and steamworks for steam integration
don't bother with line drawing support
so I'm moving the grid engine https://github.com/Planimeter/grid-sdk to lgf and making lgf a drop-in replacement for love2d that has 3d shit in it, as well as things like chromium embedded framework for ui design so im not doing this sort of shit anymore:
https://andrewmcwatters.imgur.com/all/
and other things like opus for in-game chat, and a bunch of other stuff that slime wouldn't bother implementing because it's out of love2d's scope or wouldn't be very "lovely", etc
I found a way to leverage making thin luajit ffi bindings based on mike pall's notes on ffi.cdef https://github.com/Planimeter/lffiutils so I've basically been shitting out luajit ffi bindings for anything I need and immediately working with them in lua, I don't bother trying to make alternative interfaces to the c libraries because its more bullshit to maintain; I just call the c functions directly in luajit and call it a day
I replicated a core subset of love2d's api, and added every additional feature I wanted to experiment with while teaching myself the libraries above in and opengl in just a few months, and now im working on a compat layer for the drop in work
theres a lot of love-likes out now, and the reason why is because all of the above takes such little effort
learning OpenGL, brushing up on matrix mathematics, and the libraries above has taught me a thing or two that should translate into better performance or faster development turn around for vertex adventure, so the time was well spent
I hope to get back to my 2d runescape-like soon but I think the gaming landscape has changed so dramatically that im not sure theres anyone interested in a 2d runescape unless I really try to write some compelling storyline with good jokes, compose a great soundtrack, and market it hard enough
at the end of the day, all I really want is something that I want to play, though, and if someone else likes it thats pretty cool
I wanna get back to this stuff
https://i.imgur.com/LhWUG7M.png
https://i.imgur.com/MySjk1e.png
https://i.imgur.com/uVKfZkJ.png
my dad died, I changed a bunch of different jobs, got married, and hit an early retirement goal then the us market went to shit, turned around, and is going to shit again
if you're interested in working on lgf, or the grid engine as a volunteer contributor, planimeter's old core team has moved on, and I'd love to work with lua and c gamedev enthusiasts again
very cool stuff you guys have been posting in here, I wish some more of the old timers were still around
can't wait for vertex adbenture
hey do any of you hot bois have any recommendations for a target OpenGL version? or should i just approach it feature detection style? I'm trying to keep macos support in since i do development on lgf half and half windows and mac
From my experience personally i would go with the latest you can support. I like OpenGL 4.5 a lot, but since you can't use it on MacOS you should go with 4.1 i think. Anything below that isn't worth it unless you really want to target something that doesn't support new stuff. Keep your graphics abstracted, custom framebuffers, custom vertex array, custom state creation and so on. It will make your life easier in case you run into issues later down the line and really have to either change the OpenGL version or switch to something different entirely.
Sorry, you need to Log In to post a reply to this thread.
What are you working on? v67 - March 2017
