next »

[oahda]

... I'll just leave this here.

[Canned Turkey]

But do all the devices autoupdate and autorun from your semi-hourly github autocompiled autosave?

[oahda]

I'm getting there. c;;;;

Nah.

It's all working on the command line now, and so I could definitely have one script to simultaneously compile for all platforms available on a particular machine at least. But I think I can make the effort of moving my cursor over to the other computer to pull and compile over there as well. Guess it would be a fun learning experience to set something networked up tho! But I definitely don't want automatic compiles—I do want to invoke them manually when it actually makes sense~

[JWki]

With my twitter feed being full of engine tools discussions especially on the QT/WPF/retained UI Lib vs immediate mode GUI /dear imgui approach, I decided to try out QT as I will have to for my job anyways.



Took about 15 minutes to figure out how to embed an existing native app into a QT widget, completely with docking and everything. You can just interact with it like you would with the standalone app - this is actually dear imgui within the QT app, rendered with D3D11.

I'm very seriously considering QT for the tool side in the hobby project I'm currently preparing now.
Still keeping dear imgui for embedded debugging tools and the like, especially because you can just use them within the external tooling, but for content creation it might actually make more sense for my project to use QT.

[oahda]

Cool! Back when someone (you?) linked this I was about to ask how the heck they got the separate apps in separate languages to appear in a unified window. Is that something specific to Windows or can I do it on Mac and Linux too? Especially with Qt, since it's cross-platform?


Happy because I found a command line utility to install and run my .apk on the iOS device right away, and figured out how to add a "copy bundle resources" phase to an Xcode project using the aforementioned Ruby utility, so now I've got that absolutely 100% terminal-based; a single script generates the project, builds it and then runs it on the device without me having to do anything manually, just like the Android setup was already doing!

[JWki]

Cool! Back when someone (you?) linked this I was about to ask how the heck they got the separate apps in separate languages to appear in a unified window. Is that something specific to Windows or can I do it on Mac and Linux too? Especially with Qt, since it's cross-platform?

Yeah I linked that I think.
So, the way I've done it before when all I wanted was to have the rendering output of one app within the other app was to use a shared memory region and each frame copy the framebuffer contents into that region from the rendering app, then fetch that from the displaying app and upload it to a texture. That's very very crappy and not what people usually want because usually you want input and stuff to work.

In general, if you want to have real embedding, you have to create the embedded window as a child window of the host process' window. SDL can do that out of the box afaik.
With QT, this is literally the code to do it:

Code:

WId wnd = (WId)GetRuntimeWindow();
if (wnd != 0) {
	QWindow *window = QWindow::fromWinId(wnd);
	window->setFlags(Qt::FramelessWindowHint);

	QWidget *viewportWidget = QWidget::createWindowContainer(window);
	QDockWidget *dockA = new QDockWidget("Engine Viewport");
	dockA->setWidget(viewportWidget);
	addDockWidget(Qt::DockWidgetArea::LeftDockWidgetArea, dockA);
}

GetRuntimeWindow() in this case is some windows specific hackery I do to launch the embedded process and get the window handle but it doesn't really matter how you get the window handle as long as you do. SDL exposes native handles if you want them, so that's where you'd use that. In practice I'd probably have the embedded process just hand me the window handle via TCP.

I really really like that it's that easy to do - I know how I'd do it with dear imgui if I were to do the GUI myself, but it'd be quite some cumbersome dauntwork. And it's really important for me because having the tools live in their own process without direct coupling to the runtime is very important to me.
So yeah this is really really nice and I'm looking forward to having the time to really get going with this.
The only thing I'm not buzzed about is that the build process is somewhat more involved with QT - it was easy enough to set it up to work with visual studio, but integrating that into my premake based build system will need some work.
Also I am probably going to limit the toolside to windows, at least in the short term - or until I have concrete need for it, like working with an artist or designer who's not on windows.

[oahda]

Oh, wait, I think I actually tried this once and there was a Mac-specific issue with sharing the GL context because Qt wasn't giving me a proper handle or something like that? Can't remember. q-q

[JWki]

Oh, wait, I think I actually tried this once and there was a Mac-specific issue with sharing the GL context because Qt wasn't giving me a proper handle or something like that? Can't remember. q-q

IDK about that - with the code I posted it really shouldn't occur because there's no context sharing whatsoever.
I don't even know what the QT app uses to render rn, the embedded application uses D3D11 and I assume QT is running in software mode.

[oahda]

Maybe it was the window handle to the non-Qt program I couldn't get. x:

[JWki]

On a sidenote, judging from what you posted regarding .dll loading and all that, you're planning to have your editor and engine runtime in a single process correct? Did you evaluate splitting them into two processes at all or was that just the first thing that came to mind?

[oahda]

Want to share the engine data and possibly add extra things just in-editor, so it seems difficult to do with two separate applications. x:

[JWki]

Want to share the engine data and possibly add extra things just in-editor, so it seems difficult to do with two separate applications. x:

Yeah that's a valid concern.
I'm gonna try to keep the two absolutely seperate just to see whether I can make it work - it's not absolutely necessary for my use case probably but I know it's something that devs in the AAA space tend to prefer (which makes the fact that both UE4 and Unity DONT do it seem odd) so I just want to experience it myself.
I have had good experiences with in-engine tools though.

[oahda]

Another thing I've been thinking about is to be able to run with the editor or at least a lightweight version of it even on the devices, to debug quickly and easily on the go when something is installed on a device, which seems easier then setting up some remote service or whatever. Get a console and stuff like that.

[JWki]

Another thing I've been thinking about is to be able to run with the editor or at least a lightweight version of it even on the devices, to debug quickly and easily on the go when something is installed on a device, which seems easier then setting up some remote service or whatever. Get a console and stuff like that.

Yeah that's where I think imgui really shines, to have in-game debugging UI even when the main editor is a different process.
So essentially the external editor is for like content creation, with the runtime still having debug UI to interact with all the different systems for debugging and tweaking.

[oahda]

 

[JWki]

I'm the happiest a programmer can get because completely unrelated to programming I'll hand in my thesis TOMORROW and have my talk next week so, for better or worse, I'll finally have time for programming personal stuff again!

[oahda]

Hooray!

[ferreiradaselva]

Object pooling! Object pooling!

I finally decided to implement in my engine (http://github.com/felipefs/tinycnode), and it was worth. Before I was using a linked-list, and each node (object) had its own linked-list with children. With 1000 objects (no update and no render call), my main loop was running at ~1500-1700 FPS. Now, with a object pool, 10000 (yes, 10000) nodes only hold the id of the parent, my main loop is running at ~2150 FPS. It's faaabulous!

Of course, this is v-sync disabled and no update/render call, but it's a nice benchmark. =D

[Eigen]

Object pooling! Object pooling!

I finally decided to implement in my engine (http://github.com/felipefs/tinycnode), and it was worth. Before I was using a linked-list, and each node (object) had its own linked-list with children. With 1000 objects (no update and no render call), my main loop was running at ~1500-1700 FPS. Now, with a object pool, 10000 (yes, 10000) and nodes only hold the id of the parent, my main loop is running at ~2150 FPS. It's faaabulous!

Of course, this is v-sync disabled and no update/render call, but it's a nice benchmark. =D

It is a metric, but not really a meaningful one.

https://www.mvps.org/directx/articles/fps_versus_frame_time.htm

In short:
Going from 900 to 450 FPS is around the same as going from 60 to 56 FPS, so the frames-per-second unit makes little sense when measuring code performance.

[ProgramGamer]

I'm happy.

So, a little while back I decided to learn web design in order to make a website. My plan was to have a place to host web games with some ads in order to get some money to finance a Nintendo Switch. I've made good progress on the front page design of the site, and I have a good and realistic idea of everything I want to do with it. But the only thing I was missing was how to do a good server. The only options I could see where PHP, which, I mean, gross, and Python or back end JavaScript, which, as much as I love Python, sounds like it would be slower than molasses in Siberia.

But then I discovered Go.

I've only messed around with it for about three days, but I'm already in love with how easy it is to set up a server with it. Plus, it's a compiled language with a lot of syntactic sugar, which makes it look like a mix of Python and C/C++. I'm not too sure if I'm in love with array slices yet, but I'm willing to give them a change, because the rest of the language is simply beautiful.

I'm wondering how easy it would be to program a game with it, if that would even be a good idea in the first place. It really seems to be geared towards web stuff with it's native support of threads, but then again, that's also pretty useful for games. Maybe I'll try to do a thing someday, when I'm done with the website.

Note: The site is not available yet, I'm probably only gonna publish it once I have a game to go along with it.