I wrote a ~90 line interpreter and REPL for (close to) the original LISP, in Python. Here is an example that uses the Y-combinator ([URL="http://jao.io/blog/2014/08/06/spj-s-y-combinator-in-scheme/"]copied from here[/URL]) to recursively retrieve the final element in a list.
[CODE]
LISP> (define Y
(lambda (f)
((lambda (x) (f (lambda (a) ((x x) a))))
(lambda (x) (f (lambda (a) ((x x) a)))))))
LISP> (define last
(Y (lambda (l)
(lambda (xs)
(cond
((eq (cdr xs) ()) (car xs))
(true (l (cdr xs))))))))
LISP> (last '((a . 1) (b . 2) (c . 3)))
(c . 3)
[/CODE]
[URL="https://gist.github.com/mdaisuke/2324375"]This implementation[/URL] of a slightly different kind of LISP was very inspirational and helpful, though mine turned out rather different.
anyone know if someone has used real maps to generate terrain for a game?
there is so much information you could use: topography, roads, building locations, wind intensity, vegetation density.
[QUOTE=alien_guy;52529765]anyone know if someone has used real maps to generate terrain for a game?
there is so much information you could use: topography, roads, building locations, wind intensity, vegetation density.[/QUOTE]
[url]http://www.outerra.com/wgallery.html[/url]
this maybe?
[QUOTE=alien_guy;52529765]anyone know if someone has used real maps to generate terrain for a game?
there is so much information you could use: topography, roads, building locations, wind intensity, vegetation density.[/QUOTE]
[QUOTE=Perl;52529771][url]http://www.outerra.com/wgallery.html[/url]
this maybe?[/QUOTE]
Outerra does but releases less information, especially as of late. Lots of stuff on their blog though, like:
[url]http://outerra.blogspot.com/2010/05/integrating-vector-data-roads.html[/url]
[url]http://outerra.blogspot.com/2009/06/roads.html[/url]
[url]http://outerra.blogspot.com/2015/05/evaluation-of-30m-elevation-data-in.html[/url]
Proland is also pretty helpful on this front: [url]https://proland.inrialpes.fr/[/url]
"3D Engine Design for Virtual Globes" covers a lot of your questions as well, [URL="http://www.virtualglobebook.com/"]link[/URL] plus [URL="https://github.com/virtualglobebook/OpenGlobe"]the github repo[/URL] for the book
For placing trees and doing vegetation stuff, a lot of this can be inferred from things like humidity/moisture maps along with albedo measurements for the globe. Hard to find really high resolution data, though, and compressing it can be a tremendous PITA. Outerra did some compression magics though:
[url]http://outerra.blogspot.com/2011/04/new-terrain-mapper-tool.html[/url]
Otherwise you can check around for academic papers. Couple recent ones from SIGGRAPH, maybe, haven't checked them in a few weeks. I've been too busy with work and life stuff to really sit down with my projects and dig into them, and my large-scale terrain stuff really requires me to dig in lol. Last I left it I was dealing with threading and compute job dispatching (from separate threads), so that'll be fun. That and somehow persisting data and delaying jobs based on what LOD tiles are loaded in and... yeah. Like I said, I need to dig in :v
I'm not looking for planetary scale stuff, I'm thinking detailed town scale with accurate elevation and correctly placed roads, trees, buildings.
Not just standard procedural generation.
[editline]edit[/editline]
[URL="https://wiki.openstreetmap.org/wiki/Glosm"]There is[/URL] a 3d visualiser for opensteetmap data which is essentially what i'm talking about, its not very detailed though.
Here is the full code for my LISP interpreter, in case anyone is interested: [url]https://gist.github.com/cofinite/dddf801026afec044e5ab1ed78bf87e5[/url]
[QUOTE=Radical_ed;52514395]This is going to be finished in some capacity soon as well- eventually going to be a RTS path finding engine for Unity.
[IMG]https://my.mixtape.moe/owijav.gif[/IMG][/QUOTE]
[img]https://my.mixtape.moe/ferbwp.gif[/img]
god damn that's satisfying
[QUOTE=Radical_ed;52530926][img]https://my.mixtape.moe/ferbwp.gif[/img]
god damn that's satisfying[/QUOTE]
I'm getting some galcon vibes when looking at your swarms
[QUOTE=Radical_ed;52530926][img]https://my.mixtape.moe/ferbwp.gif[/img]
god damn that's satisfying[/QUOTE]
Is that a combination of A* Star pathing along with Boid movements or other flocking movements? Cause holy shit that looks so goooooood.
[QUOTE=BlackMageMari;52531516]Is that a combination of A* Star pathing along with Boid movements or other flocking movements? Cause holy shit that looks so goooooood.[/QUOTE]
Looks more like flow fields to me
I wonder if you could use compute shaders on that and then crank the unit count up into the high thousands. :magic101:
[QUOTE=alien_guy;52529765]anyone know if someone has used real maps to generate terrain for a game?
there is so much information you could use: topography, roads, building locations, wind intensity, vegetation density.[/QUOTE]
[url]https://www.theregister.co.uk/2014/04/24/minecraft_players_can_now_download_denmark_in_11_scale/[/url]
shit, was going to post dumb question on how to apply low-pass filter SMOOTHLY when the problem was just in huge buffer size setting
Want the [URL="https://blogs.msdn.microsoft.com/commandline/2017/08/02/updating-the-windows-console-colors/"]new Win10 cmd color [/URL]scheme, but don't want to install a clean build of windows just for that? Well, [URL="https://gist.github.com/Foda/3b7824bb8e08a459df651745110c1942"]here you go [/URL]
Its probably worth adding, that you can do the same for other terminals or powershell/xterm/git-bash, you can use the same settings in the subfolders of HKEY_CURRENT_USER\Console
Eg
Computer\HKEY_CURRENT_USER\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe
[QUOTE=Foda;52536378]Want the [URL="https://blogs.msdn.microsoft.com/commandline/2017/08/02/updating-the-windows-console-colors/"]new Win10 cmd color [/URL]scheme, but don't want to install a clean build of windows just for that? Well, [URL="https://gist.github.com/Foda/3b7824bb8e08a459df651745110c1942"]here you go [/URL][/QUOTE]
[QUOTE]So how will you see the new color scheme if you have upgraded from a previous build? We'll soon be publishing a tool that will help you apply this new scheme and a selection of alternative color schemes to your Windows Console. Stay tuned for more details.[/QUOTE]
Started to think about low level rendering apis (again), inspired by [URL="http://floooh.github.io/2017/07/29/sokol-gfx-tour.html"]thisl[/URL] to try and come up with something that's similarly straightforward but more geared towards the desktop APIs and also could support Vulkan and D3D12. My past attempts at this were trying to be way too thin, so this time I'm consciously trying to make the surface API pretty simple and thus allowing the implementation more freedom. This may not lead to optimal API usage but I feel like enhanced productivity is a more important factor for my use cases.
This snippet shows how you'd select the default graphics device in the system and then create two buffers to use for rendering:
[code]
gfx::Interface* gfxInterface = nullptr;
gfx::Device* gfxDevice = nullptr;
gfx::InterfaceDesc interfaceDesc;
if (!gfx::CreateInterface(&gfxInterface, &interfaceDesc, &applicationArena)) {
GT_LOG_ERROR("Renderer", "Failed to initialize graphics interface\n");
}
gfx::DeviceInfo deviceInfo[GFX_DEFAULT_MAX_NUM_DEVICES];
uint32_t numDevices = 0;
gfx::EnumerateDevices(gfxInterface, deviceInfo, &numDevices);
for (uint32_t i = 0; i < numDevices; ++i) {
GT_LOG_INFO("Renderer", "Detected graphics device: %s", deviceInfo[i].friendlyName);
}
if (numDevices == 0) {
GT_LOG_ERROR("Renderer", "No graphics device detected!");
}
else {
gfxDevice = gfx::GetDevice(gfxInterface, deviceInfo[0].index);
if (gfxDevice != nullptr) {
GT_LOG_INFO("Renderer", "Selected graphics device: %s", deviceInfo[0].friendlyName);
}
else {
GT_LOG_ERROR("Renderer", "Failed to get default graphics device");
}
}
gfx::BufferDesc vBufferDesc;
vBufferDesc.type = gfx::BufferType::BUFFER_TYPE_VERTEX;
vBufferDesc.initialData = triangleVertices;
vBufferDesc.initialDataSize = sizeof(triangleVertices);
gfx::Buffer vBuffer = gfx::CreateBuffer(gfxDevice, &vBufferDesc);
gfx::BufferDesc iBufferDesc;
iBufferDesc.type = gfx::BufferType::BUFFER_TYPE_VERTEX;
iBufferDesc.initialData = triangleIndices;
iBufferDesc.initialDataSize = sizeof(triangleIndices);
gfx::Buffer iBuffer = gfx::CreateBuffer(gfxDevice, &iBufferDesc);
[/code]
Creation of other resources looks pretty much the same.
Now this is the straightforward part of it, the interesting bit will be draw call recording and submission - I want to be able to multithread command recording, so APIs that don't support that (OpenGL) have to emulate it under the hood which should be straightforward given the fact that this is supposed to be a stateless API (draw calls are completely self contained, no state machine bullshit), so emulating command buffers in OpenGL just means recording the draw call states and then playing them back on the main thread instead of recording actual API command buffers. I'm not even sure I'm going to implement OpenGL for this tho, as Vulkan covers pretty much all platforms that OpenGL would give me (except for Apple, but I don't have any Apple hardware to test on anyways, and well Metal is supposed to be good so).
[QUOTE=JWki;52538549]Started to think about low level rendering apis (again), inspired by [URL="http://floooh.github.io/2017/07/29/sokol-gfx-tour.html"]thisl[/URL] to try and come up with something that's similarly straightforward but more geared towards the desktop APIs and also could support Vulkan and D3D12. My past attempts at this were trying to be way too thin, so this time I'm consciously trying to make the surface API pretty simple and thus allowing the implementation more freedom. This may not lead to optimal API usage but I feel like enhanced productivity is a more important factor for my use cases.
This snippet shows how you'd select the default graphics device in the system and then create two buffers to use for rendering:
[code]
gfx::Interface* gfxInterface = nullptr;
gfx::Device* gfxDevice = nullptr;
gfx::InterfaceDesc interfaceDesc;
if (!gfx::CreateInterface(&gfxInterface, &interfaceDesc, &applicationArena)) {
GT_LOG_ERROR("Renderer", "Failed to initialize graphics interface\n");
}
gfx::DeviceInfo deviceInfo[GFX_DEFAULT_MAX_NUM_DEVICES];
uint32_t numDevices = 0;
gfx::EnumerateDevices(gfxInterface, deviceInfo, &numDevices);
for (uint32_t i = 0; i < numDevices; ++i) {
GT_LOG_INFO("Renderer", "Detected graphics device: %s", deviceInfo[i].friendlyName);
}
if (numDevices == 0) {
GT_LOG_ERROR("Renderer", "No graphics device detected!");
}
else {
gfxDevice = gfx::GetDevice(gfxInterface, deviceInfo[0].index);
if (gfxDevice != nullptr) {
GT_LOG_INFO("Renderer", "Selected graphics device: %s", deviceInfo[0].friendlyName);
}
else {
GT_LOG_ERROR("Renderer", "Failed to get default graphics device");
}
}
gfx::BufferDesc vBufferDesc;
vBufferDesc.type = gfx::BufferType::BUFFER_TYPE_VERTEX;
vBufferDesc.initialData = triangleVertices;
vBufferDesc.initialDataSize = sizeof(triangleVertices);
gfx::Buffer vBuffer = gfx::CreateBuffer(gfxDevice, &vBufferDesc);
gfx::BufferDesc iBufferDesc;
iBufferDesc.type = gfx::BufferType::BUFFER_TYPE_VERTEX;
iBufferDesc.initialData = triangleIndices;
iBufferDesc.initialDataSize = sizeof(triangleIndices);
gfx::Buffer iBuffer = gfx::CreateBuffer(gfxDevice, &iBufferDesc);
[/code]
Creation of other resources looks pretty much the same.
Now this is the straightforward part of it, the interesting bit will be draw call recording and submission - I want to be able to multithread command recording, so APIs that don't support that (OpenGL) have to emulate it under the hood which should be straightforward given the fact that this is supposed to be a stateless API (draw calls are completely self contained, no state machine bullshit), so emulating command buffers in OpenGL just means recording the draw call states and then playing them back on the main thread instead of recording actual API command buffers. I'm not even sure I'm going to implement OpenGL for this tho, as Vulkan covers pretty much all platforms that OpenGL would give me (except for Apple, but I don't have any Apple hardware to test on anyways, and well Metal is supposed to be good so).[/QUOTE]
Idk if I'd bother supporting OpenGL after using things like D3D12/Vulkan that give you such explicit control. So many wrappers exist for OpenGL already, and there's not a ton to be gained by wrapping things like there is with the more advanced APIs. Plus emulating multithreaded command recording would kinda suck, and even with DSA OpenGL is still a bit too stateful for my taste. Why so many raw pointers though, and passing pointers to your create functions?
On another note, after spending an hour trying to get basic functionality of my rendering stuff exported to a DLL I've decided that DLL's are a silly (wretched) place and we shall not go there again
[QUOTE=paindoc;52539106]Idk if I'd bother supporting OpenGL after using things like D3D12/Vulkan that give you such explicit control. So many wrappers exist for OpenGL already, and there's not a ton to be gained by wrapping things like there is with the more advanced APIs. Plus emulating multithreaded command recording would kinda suck, and even with DSA OpenGL is still a bit too stateful for my taste. Why so many raw pointers though, and passing pointers to your create functions?
On another note, after spending an hour trying to get basic functionality of my rendering stuff exported to a DLL I've decided that DLL's are a silly (wretched) place and we shall not go there again[/QUOTE]
Hahaha dlls are quite fun actually once you get into it! I've used them with great pleasure to implement hot reload for C++ code before.
Regarding OpenGL support, that's purely academic - I'm probably not going to bother with it. But it might actually be quicker to implement an OpenGL backend than a Vulkan backend so just to get stuff running on Linux it might be the easier route. But I'm never going to like maintain an OpenGL codebase again I don't think.
I AM in fact implementing this in D3D11 first atm tho just because that's the most accessible API I've used to date and it also happens to cover 90 percent of my short term use.
Regarding the raw pointer usage - is there a problem with that? Resources are referenced by handle (gfx::Buffer is a (typesafe) 32 bit integer with the 16 lower bit indexing into a resource pool and the upper 16 bit containing a generation counter to detect stale handle accesses).
Regarding passing pointers to my create functions, you have used Vulkan so you should be used to seeing stuff like that. TBF I'm thinking about passing the descriptor structs per value instead because I copy them into the corresponding resource struct in the implementation anyways to be able to look them up later.
[QUOTE=JWki;52539270]Hahaha dlls are quite fun actually once you get into it! I've used them with great pleasure to implement hot reload for C++ code before.
Regarding OpenGL support, that's purely academic - I'm probably not going to bother with it. But it might actually be quicker to implement an OpenGL backend than a Vulkan backend so just to get stuff running on Linux it might be the easier route. But I'm never going to like maintain an OpenGL codebase again I don't think.
I AM in fact implementing this in D3D11 first atm tho just because that's the most accessible API I've used to date and it also happens to cover 90 percent of my short term use.
Regarding the raw pointer usage - is there a problem with that? Resources are referenced by handle (gfx::Buffer is a (typesafe) 32 bit integer with the 16 lower bit indexing into a resource pool and the upper 16 bit containing a generation counter to detect stale handle accesses).
Regarding passing pointers to my create functions, you have used Vulkan so you should be used to seeing stuff like that. TBF I'm thinking about passing the descriptor structs per value instead because I copy them into the corresponding resource struct in the implementation anyways to be able to look them up later.[/QUOTE]
I've been in the habit of replacing most raw pointers in my code with two things: in the case of passed parameters, I try to use const references. can still get a pointer from that, but it makes it harder to pass a null value. For the other case of resources/classes I'm creating or using, I've found std::unique_ptr works well and has been an easy drop-in replacement for raw pointers in my code. It has very little overhead (if any, based on what I've read it shouldn't even have overhead tbh) and still lets me choose initialization time and order, which is pretty important with Vulkan. Neither of these are absolutes though: sometimes passing a pointer is useful ofc because you want to be able to set a null value. And in the case of your handles, it makes sense why you're doing that since its not actually a class that you're pointing to. I'm used to seeing stuff like that in Vulkan, but I still prefer to wrap most of that stuff in some kind of RAII when applicable
Regarding DLLs: Outside of binary compatability concerns, I had no real reason to try it beyond curiosity. It has told me that using the pimpl idiom would be required, and I am quite averse to doing that since building a static library is working fine for me currently (especially now that I've got my cmakelists.txt working wonderfully). I can see trying it again for hot reload of certain things down the road, but I still have a lot of work on just my base rendering code I need to get implemented first.
[QUOTE=paindoc;52539353]I've been in the habit of replacing most raw pointers in my code with two things: in the case of passed parameters, I try to use const references. can still get a pointer from that, but it makes it harder to pass a null value. For the other case of resources/classes I'm creating or using, I've found std::unique_ptr works well and has been an easy drop-in replacement for raw pointers in my code. It has very little overhead (if any, based on what I've read it shouldn't even have overhead tbh) and still lets me choose initialization time and order, which is pretty important with Vulkan. Neither of these are absolutes though: sometimes passing a pointer is useful ofc because you want to be able to set a null value. And in the case of your handles, it makes sense why you're doing that since its not actually a class that you're pointing to. I'm used to seeing stuff like that in Vulkan, but I still prefer to wrap most of that stuff in some kind of RAII when applicable
Regarding DLLs: Outside of binary compatability concerns, I had no real reason to try it beyond curiosity. It has told me that using the pimpl idiom would be required, and I am quite averse to doing that since building a static library is working fine for me currently (especially now that I've got my cmakelists.txt working wonderfully). I can see trying it again for hot reload of certain things down the road, but I still have a lot of work on just my base rendering code I need to get implemented first.[/QUOTE]
I'm not a friend of RAII in general tbh - I very much prefer very explicit initialization and shutdown mechanisms with some sort of rigid checking for correctness via tools or internal sanity layers.
I tend to avoid references as well because I'm a fan of consistency and I find it easier to just use pointers everywhere instead of having a mix of pointers and references. Obviously it's a case-by-case thing - sometimes it's better to pass small things by value actually because it'll actually reduce the amount of copies being made, or cause less memory to be copied. Or in my case I might want to actually change inputs within the function which obviously will have side effects when passing by pointer.
I appreciate that there's situations where the semantics that std::unique_pointer offers are helpful however I also believe that such mechanisms should live in layers higher than what a low level graphics API plays in. As in, if you HAVE a use case that benefits from automated ownership management, then for that use case you should have helper classes or whatever that work on top of the low level API, but an API should not impose that on every use case.
EDIT:
Here we fucking go, API agnostic hello triangle.
[IMG]https://puu.sh/x1Gcz/f514d1353b.png[/IMG]
The last time I felt so happy about a stupid fucking triangle was when I did that Vulkan tutorial.
EDITEDIT: Also, I know it has been mentioned before, but holy shit is RenderDoc a godsend.
Obviously the first time I tried to render that damn triangle there was nothing on my screen but with RenderDoc I managed to find the issues within minutes.
[QUOTE=JWki;52539397]-hello triangle-[/QUOTE]
RenderDoc is the best. I really like how debug markers work in Vulkan, and that you can set colors with them. It makes isolating drawcalls by category and purpose so much easier. I'm really thinking that LunarG packaging RenderDoc and RenderDoc being so well tied into Vulkan is going to lead to better features down the road: I'm hoping for things like pixel history and more in-depth shader debugging, and maybe some of the neat features from NSight (without dealing with Nvidia). In regards to the rest of your post, I see what you mean but I've just found std::unique_ptr to work really well. Its so thin that at this point we're practically debating syntactical differences, which is using "std::make_unique" vs "new" and using "std::unique_ptr.reset()" vs "delete" (and to be fair, in the case of Vulkan, I do have to actually call reset() at times for certain objects that have to be destroyed before others).
On the topic of Vulkan though, I'm thinking of adding my vulkan memory allocator to dolphin-emu. I branched it and started setting it up a few days ago, and think that it might be a nice feature to add: even if it doesn't increase performance a ton, it greatly simplifies resource management (from creation to destruction to ownership tracking) in the rest of the program, but I'm worried about how well it will function on a wide range of hardware. Plus, I still think it'll need some kind of defrag routine unless I redesign the system a bit. Ultimately, my attempt at "helping" may just be harmful :v
[editline]5th August 2017[/editline]
[QUOTE=alien_guy;52529846]I'm not looking for planetary scale stuff, I'm thinking detailed town scale with accurate elevation and correctly placed roads, trees, buildings.
Not just standard procedural generation.
[editline]edit[/editline]
[URL="https://wiki.openstreetmap.org/wiki/Glosm"]There is[/URL] a 3d visualiser for opensteetmap data which is essentially what i'm talking about, its not very detailed though.[/QUOTE]
To be fair, the vector data stuff is still going to apply no matter what scale you work at (iirc)
This is my "hello world" in SDL
[vid]https://s1.webmshare.com/B7yW1.webm[/vid]
The video appears to be broken... So it looks a lot like my SDL experience! :v:
[QUOTE=blakeguy25;52542557]The video appears to be broken... So it looks a lot like my SDL experience! :v:[/QUOTE]
Looks like your Chrome experience cause it appears for me :/
[QUOTE=proboardslol;52542635]Looks like your Chrome experience cause it appears for me :/[/QUOTE]
I get a 404 on the url: [url]https://s1.webmshare.com/B7yW1.webm[/url]
[b]EDIT:[/b]
This is the weirdest shit; it loads fine in Chrome if I copy + paste the URL. Looks like webmshare hates Facepunch (or any) referrals.
Yeah and it's no longer working for me.
What is a good webm host?
[QUOTE=paindoc;52542317]RenderDoc is the best. I really like how debug markers work in Vulkan, and that you can set colors with them. It makes isolating drawcalls by category and purpose so much easier. I'm really thinking that LunarG packaging RenderDoc and RenderDoc being so well tied into Vulkan is going to lead to better features down the road: I'm hoping for things like pixel history and more in-depth shader debugging, and maybe some of the neat features from NSight (without dealing with Nvidia). In regards to the rest of your post, I see what you mean but I've just found std::unique_ptr to work really well. Its so thin that at this point we're practically debating syntactical differences, which is using "std::make_unique" vs "new" and using "std::unique_ptr.reset()" vs "delete" (and to be fair, in the case of Vulkan, I do have to actually call reset() at times for certain objects that have to be destroyed before others).
On the topic of Vulkan though, I'm thinking of adding my vulkan memory allocator to dolphin-emu. I branched it and started setting it up a few days ago, and think that it might be a nice feature to add: even if it doesn't increase performance a ton, it greatly simplifies resource management (from creation to destruction to ownership tracking) in the rest of the program, but I'm worried about how well it will function on a wide range of hardware. Plus, I still think it'll need some kind of defrag routine unless I redesign the system a bit. Ultimately, my attempt at "helping" may just be harmful :v
[editline]5th August 2017[/editline]
To be fair, the vector data stuff is still going to apply no matter what scale you work at (iirc)[/QUOTE]
Oh does RenderDoc not have pixel history for Vulkan yet? It does for D3D11.
Regarding std::unique_ptr - it is thin, yes, but a thin wrapper over new and delete still manages the object lifetime with new and delete - which I don't do because in my code memory management and object initialization/shutdown are separate issues. I do initialize objects while I claim memory for them a lot, but that memory is always preallocated and when initializing an object into a memory section that always follows a strategy that makes sense for the lifetime of that object. For example, all things that have allocation lifetime are allocated in a linear fashion from a big chunk of memory (~2GB in a development build) which is as simple as bumping a pointer, and the whole chunk is just freed when the application shuts down - or never, because freeing memory at the application exit doesn't really make sense.
There's cases where I go for a general purpose allocator (which I obviously don't write myself because I'm not crazy) but even then it's all behind the same interface to make stuff like tracking and bounds checking non-intrusive and simple. std::unique_ptr just doesn't fit well into that scheme.
I do use it fairly frequently at work tho - the codebase I'm working in goes completely haywire with allocations anyways, and when the policy is free allocations everywhere then std::unique_ptr is actually helpful for staying sane.
EDIT: Also, here's a thing that's a pleasure in D3D / Vulkan and has always been kind of a pain in OpenGL: Multi window is trivial because you manage your swap chains yourself (with some extra work in D3D)
[IMG]https://puu.sh/x2wrh/df759b31c1.png[/IMG]
It's even more of a pleasure now that my wrapper supports it:
[CODE]
gfx::SwapChainDesc swapChainDesc;
swapChainDesc.width = WINDOW_WIDTH;
swapChainDesc.height = WINDOW_HEIGHT;
swapChainDesc.window = g_hwnd;
gfx::SwapChain swapChain = gfx::CreateSwapChain(gfxDevice, &swapChainDesc);
if (!GFX_CHECK_RESOURCE(swapChain)) {
GT_LOG_ERROR("Renderer", "Failed to create swap chain");
}
gfx::SwapChain secondSwapChain;
swapChainDesc.window = secondaryWindow;
secondSwapChain = gfx::CreateSwapChain(gfxDevice, &swapChainDesc);
if (!GFX_CHECK_RESOURCE(secondSwapChain)) {
GT_LOG_ERROR("Renderer", "Failed to create swap chain");
}
[/CODE]
EDITEDIT: Also just realized that this amongst a few other tiny features I introduced may have killed OpenGL support for my API. Whoops.
[QUOTE=proboardslol;52542850]Yeah and it's no longer working for me.
What is a good webm host?[/QUOTE]
any pomf clone really
[url]https://docs.google.com/spreadsheets/d/1kh1TZdtyX7UlRd55OBxf7DB-JGj2rsfWckI0FPQRYhE/edit#gid=0[/url]
[QUOTE=proboardslol;52542850]Yeah and it's no longer working for me.
What is a good webm host?[/QUOTE]
Mixtape.moe, I've heard it has a bad reputation due to certain people who use it, but I really don't give a shit about any of that. It does exactly what it needs to do and sharing videos (especially using ShareX) is super easy.
No complaints from me whatsoever!
Sorry, you need to Log In to post a reply to this thread.
What are you working on? v67 - March 2017
