Відео

You're the kind of game developer I love. I've seen to many dev logs recently where they shuck on 5 post processing shaders and call it a day so their "retro" indie game takes 5 GB and needs a 1080ti to run.

Back when Yuzu still existed I was trying to get my potato to run TotK without stuttering because of the shader compiling and brainstorming with some other people. Eventually one of them suggested I just download a TAS speedrun of the game and let it compile the game for me.

Dev stuff aside this game looks really cool. Like a melee focused Turbo Overkill with how flowy that movement looks.

bro making ultrastab

thats awesome dude, optimisation is a neglected area across software development these days. even some websites are bloated beyond belief. optimisation reduces e-waste! :)

A better pattern for the pathing stuff, FYI, is to use a round-robin scheduler. So you set a budget for how many agents are allowed to update on a given frame, and each frame you have a manager move the index by n slots and update that many agents. So you can guarantee a fixed load per frame and also guarantee that an agent only goes so many frames between updates. You can use this pattern for a lot of things to smooth out your load to be precisely consistent over time.

sweet new movement game lets go W

Unreal compiles with directx 11, 12 and vulkan at the same time but i don't know what variables you need to change to switch the driver

Thank you for making the game available for Linux

The question is now that you have optimized it for potatos, can you do the same for tomatoes?

Open 3D Engine or O3DE primarily has support for DX12, Vulkan, and something called Metal 2...which is Apple-specific nonsense. its renderer is...something they call "Atom physically-based renderer". Its fun. You can also force it to render in OGL, but it seems streamlined just for Vulkan.

7:17 valvve fixed this issue on the Steam Deck/LInux, they pre-compile the shaders and we download it as an update edit: that dxvk if the steam pre-compiled shaders that i was talking about lmao

You should absolutely have the loading screens cycle through different titles like "Loading Game" "Compiling Shaders" Just so one of them can say "Beating Level For You" or something in reference to a replay being played in the background to generate the shaders

make it hard to tell what the limits of your game is, primarily by making the limits hard to reach without expecting a speedrunner skill level but still rewarding them for having that skill, or boring the player to death in the process by making the limits take a long period of repetition to reach (like grinding). many platformers are great at this, Like Mario 64 and Pseudoregalia. im happy to be seeing more speedrun friendly, parkour focused games like these being made. this type of genre never went out of style, its just not as easily implemented in the huge open worlds that games have been focusing on for awhile now.

now make it run on a real potato

Fun fact, DirectX 1 (yes, first) gives you 60 fps under WinXP with geforce 9600 rig and 10 fps on rtx 3090 under Windows 10. And they have different artifacts in addition. My biggest problem was actually even modern really shitty celerons you can find in Chinese x86 100 bucks box PCs doesn't support modern SSE and if you compile your code with wrong SSE version ... well, you guessed it, it will find unknown instruction. Overall I would recommend you to buy one of this boxes for testing. The best way to support old hardware would be actually DirectX 9. Cause OpenGL 2 was ... just ... better not to think of it. But yeah, doubt we'll see DirectX 9 ever in big modern engines. And actually even geforce 9600 supports DirectX 10 and I've got it for 10 bucks. I personally use DirectX 9 it for my retro engine. Just because ... for anything better better to take Vulkan.

Oh man, you can't imagine how many PS1 era games had this "occluded but not really so hidden" parts of the scene or objects disappear and break immersion ... it's not a bug, it's a feature.

i haven't seen anyone mention this: fps differences are not a good way to compare performance improvements, because fps being inverse to duration makes differences relative to where you started from. you can use ratios for a general overview, but if you want to compare specific changes, differences in average frametime won't depend on how much work every other subsystem is doing. as an example, occlusion culling had an fps difference of 50, or a ratio of 1.5x, starting from 100 fps. baked lighting had an fps difference of 120, or a ratio of 2x, starting from 120 fps. the fps difference makes it seem like baked lighting was over twice as effective as occlusion culling, but the differences in frametime are ~3.3ms and ~4.2ms respectively. as for why not to use ratios to compare specific changes, while occlusion culling and baked lighting are probably not independent of each other, if some other area of your game were performing worse (and wasn't masked by parallelism) and the baked lighting timesave of ~4.2ms started from 100 fps, it would have had an fps difference of 72, or a ratio of 1.72x, instead of 2x. "did you spend 6 months to only optimize this game by 50 fps???" is another example of the confusion this can cause. going from 9 fps to even 54 fps (only a 45 fps difference!) is a whopping 93ms difference, and a ratio of 6x. this was a great video, thank you for sharing!

capcom games do that same shader compilation thing! i think!

5:40 smiley face :D

putting a video of a level as the loading screen would be awesome, you should put it in your game

maybe you can add an "old videocard support" checkbox to use openGl instead of vulkan, but idk if that works

If you consider 7th generation Intel i3 CPU + 4GB ram PC as potato, you have never been in Turkey.

The fact a game that looks like that needs optimization in the first place is quite funny, not using PBR would bring a massive performance increase, the replacement doesn't even have to be Phong, although Phong is extremely cheap

5:45 How about you do it based on range? Give the closest enemies priority for pathfinding (since they are the ones most likely to be closely observed by the player) and then decrease the amount of updates the further away the other enemies are (since they need to cover more distance anyway so they have more time to adjust)?

Wow i don"t get why it ran that bad at first though from what it seems, it was cpu bottleneck and also using qodot instead of optimized blender meshes

A little tip I learned from studying the level design in ULTRAKILL is: Make movement so that your players can get anywhere, and then design levels around that. Right now, your movement in Blood Thief is already pretty much there, there's a huge amount of freedom in where you can go. So what you can do with that freedom is design levels without having to worry about where the player can or can't go (for the most part). Obviously test things beforehand. But always physically block off out of bounds spaces with the assumption that players will find ways to get there, or try putting secrets or collectables in places like that. Just make sure if you place a secret that you actually test to make sure it's absolutely possible. The more freedom you give your movement system, the more whacky places you can put secrets, but Blood Thief's movement already opens up a lot of potential

This was a super simple and helpful explanation! Thank you!

Not sure about Unreal, but in Unity, you add all the graphics APIs you want supported in the project settings. Then when the game launches for each client, it goes through the list of APIs, selecting the first one that the client's hardware supports.

Why not have one version for OpenGL and one version for Vulkan? I know there's other games that let you choose.

That's AMAZING, love the random sounds from the loading screen. Maybe a funny animation would pair well with it Edit: You put it best though! "Frantically cleaning castle!" or something, and have a couple little pixel enemies zipping around 😂

how much work would it be to implement both vulcan and opengl?

If you can I will like to see this game on consoles like xbox one and x/s and ps4 and ps5 and Nintendo switch when is not in early access and if you can afford it keep up the good work.

Some of your textures appear to have VRAM compression which splits them up into blocks of different colors, you may want to disable it in the import setting as it looks wierd on low res textures

Nice video! I'm trying to write a software+ogl1 game engine for even potato-er computers. This is very inspirational to me.

Me and the boys baking lights

$290 !???? I'm using a Thinkpad T480 i got for $150 used. I replaced the SSD and RAM to get 2TB and 16GB. it's fantastic value, just look for used business Laptops

Watched your video and instantly subbed for the playtesters. Loved the game. Keep it up!

Oh man, it would be AMAZING while loading to see (the example at 12:04) and hear (the example at 12:31) the whole level being played, while the game is loading! A bit like a "sneak peak" of what to expect! PLEASE ADD IT, at least as an option you can toggle!!! 😂😂😂

This is so cool... As a 90s kid I grew up on level design like this and even learned how to use the old Unreal One engine for making Deus Ex maps. Learning Godot now I decided I wanna go back to doing level design like this even if I'm really good in Blender now. Trenchbroom is interesting, but I'm currently using Cyclops right now which is kinda like Trenchbroom but as a plug-in for Godot where I use Godot as a level editor directly. I hope tools like this really evolve as the industry seems to have given up on them, which I feel was a mistake as level design and modeling are pretty different in scope and ideally suited to their own program. I can make one amazing looking flower vase in Blender now, and while sure I could make nice looking maps in Blender too, if I gotta change anything it would become one massive UV/texturing headache to redo any part of it. Cyclops lets me make a map, then change it quickly if I don't like it without needing to redo all the UVs and what not, that's really why Level editing and 3d Modding should be done in their own respective programs I feel.

Your solution for compiling shaders is brilliant!

so the problem with vulkan, iiiiiis the same problem as with dx12 and that is the GPUs were forced to use spir-v instead of their own implementations. this did fixed a LOT like A LOT of problems caused by gpu manufacturers. but it comes with the caveat of earlier hardware not supporting it. Now when it comes to intel that is a whole other can of worms, as their gpu hardware and software used to leave a lot to be desired. iirc the first spir-v implementations were essentially just running the code on the cpu side in the driver it self (cries irl)

I've been gaming on a i3-3120m for almost a decade just fine, your laptop can't be that bad :P

Teeeeechnically it has a gpu but it’s just integrated

Finally a Devlog thats not just a plain Daily Diary. Thats exactly how a Devlog should be. I wish you your game does well. Even if im not into 3D Platformer this game looks still like alot of fun! Great Job Blargis!

9:16 this voiced one of those concerns that I could never find the right words for, just had a feeling for. Thank you.

I spent nearly 2 years developing a Video game and it can barely get 40 FPS on a RTX 1600 Ti with 16 Gigs Ram Intel i7 11th Gen. Okay that is on Max graphic settings on lower it gets about 500 Fps.

You couldve maybe used a vm to replicate the shader stutters?

I wonder, I know the game looks fkn borked in OpenGL, but I wonder if there's a way to detect if the player's computer doesn't support Vulkan, and swap to OpenGL as a fallback? I also wonder if there's a way to create OpenGL exclusive fixes to make the game not look like a complete disaster if the fallback is required.