It shows a Move Permanently message.
What the hell? It was just up, I even checked the link. Iāll try to fix it.
Finally started learning OpenGL with C++
I was reading up about design patterns and I found this: https://sourcemaking.com/design_patterns
Itās a list of design patterns for those who feel like learning how to use them.
Added more items and recipes to Vangard.
PS: Writing a hnefatafl AI is hard!
Cool, thanks! Thatās definitely gonna be useful.
Been working on lots of different things, as well as getting all bogged down by school. Reworked our sound engine completely, fixed multiple OGG streams (a static sample buffer? REALLY?!), etc, etcā¦
Anyway, I implemented a nice little idea I had while chatting with orange451 regarding skyboxes today. The problem with all the nice-looking skyboxes online is that theyāre not HDR. They often have a sun or bright stars or whatever on them that just end up looking gray and dull when drawn in a HDR game. For example, both a somewhat bright cloud and the gigantic bloom of the sun are both ~0.95-0.98 brightness, but the HDR difference between them is of course huge (>2 magnitudes). Theyāll essentially be equally bright, even though the 0.03 brighter sun should 100 brighter and bloom as hell (not just be a picture with bloom added to it). The problem is that photos used for sky boxes are essentially ātone mappedā to LDR by the physical limitations of the camera and then saved in common LDR formats, so information is somewhat lost. However, itās possible to partly kinda reconstruct the HDR colors byā¦ using an inverse tone mapping function. x___x The idea is to take the inverse of a simple tone-mapping function like (color / (1+color)) and apply that to the read LDR colors. Itās actually fairly accurate, but we get very low bit precision at higher colors. We also have a problem with the tone mapping functionās output approaching 1.0 when the light approaches infinity, so if the skybox contains perfect white 1.0 we end up calculating an infinite HDR color, so some tweaking needs to be done. Anyway, I tried it out. The left half of the image shows the inverse tone mapped sky box, while the right one shows the usual LDR sky box.
(Please right-click the image and open it in a new tab to get a much higher resolution image!)
We can see that the really bright stars and the blue nebula things are much brighter on the left half of the image, even triggering my HQ bloom filter that can bleed over foreground objectsā¦ The right side stars look duller andā¦ fake, as their bloom is baked into the skybox. Theyāre not as bright as they should be.
Hereās a second image of the same sky with a massive amount of HDR-correct motion blur applied. The dull right-hand side stars almost completely disappear as theyāre smeared out since theyāre already so dim, but the inverse tone-mapped stars explode into awesome looking streaks thanks to their HDR colors. It looks amazing and really catches your eye in motion.
This is essentially only useful for the night sky in WSW, as the atmospheric scattering during the day is calculated based on physical algorithms and produced in HDR already, but it really adds a kick to the night stars!
EDIT: Bonus picture with HDR applied to the whole screen!
EDIT2: Kinda looks like the FF7 opening movieā¦ =P
I did some web development today, and rewrote @ra4kingās FancyBot powered IRC log viewer. It is now completely responsive (tested on mobile).
All the logs are fetched from Roiās server with the help of his JSON API, and rendered client side. There is also another feature, we can customize the timezone of the day to be fetched!
Just change [icode]?date=09+May+2016[/icode] to [icode]?date=09+May+2016+GMT[/icode] for times in GMT, or [icode]?date=09+May+2016+%2b0230[/icode] to get the times in GMT +2:30 time zone.
If no time zone is specified, the times are displayed in the clientās system timezone. The times in the left bar are always shown in the clientās timezone. This will get up online probably tomorrow, after tweaking the mobile layout a bit more (two grid cells is too much there).
Hi lads! 
'Til now, this is how my loading screens worked:
[Fade-in starts]ā¦[Fade-in ends][Loading starts]ā¦[Loading ends][Fade-out starts]ā¦[Fade-out ends]
Very suboptimal.
It worked all right, because I didnāt have a lot of resources to load so it would just fade in then fade out. However, Iāve been adding quite a lot of textures and fonts lately, so the loading time became longer. Today, I decided to change my loading screen patterns to:
[Loading starts]ā¦[Loading ends]
[Fade-in starts]ā¦[Fade-in ends]ā¦[Fade-out starts]ā¦[Fade-out ends]
As you can observe, the fade-in and the loading now start at the same time; the fade-out starts whenever the loading ends. However, as resources become longer and longer to load (this afternoon I hit ~450 ms), Iām thinking of removing the fade-out in order to gain extra time and make it more bearable. But with no fade-out, it just looks awkward :emo:
Of course, it would be impossible to make the fade-out end exactly at the same time as the buffering. I guess I could find a way to start the fade-out at an approximated time so that it would end more or less at the same moment as the buffering.
How would you cope with this problem? Delete completely the fade-out, leave it as is, approximate?
(I should probably mention that the fade-in and fade-out times are about 150 ms each)
J0
just reduce the fade out time, if the loading is too long to spare less than a quarter second Iām not really sure the fading is the problem. The jump from a load screen into a game is just fine.
[quote=āJ01,post:4231,topic:49634ā]
[quote=āJ01,post:4231,topic:49634ā]
Total of 700ms load timeā¦ thatās less than a second. Youāre fine.
As long as you are below 5 or 15 seconds (depending on if you show loading screen on every level/area loading or only once when game is starting) you donāt have anything to worry about.
I appreciate every effort game developers make to reduce load times. Iām disappointed that multithreaded loading is not more common in CPU limited loadsā¦
It is not nearly as easy as it looks to make work. I know i tried it. You end up with lots of OS wait states. Really you can only read stuff from disk so fast and for the most part having a not stupid on disk format is about as good as it gets. But max IO bandwidth is not realized if your also trying to get max data to the GPU etc. In theory it can work. But even million dollar GIS systems come with custom configurations often enough to reduce the problems with streaming data.
Compression is a good thing for lowering load time.
And in other news: https://renderdoc.org/vulkan-in-30-minutes.html
The fastest i have found is store it the same as in memory. Use simple fast compression. None of the xz or bzip stuff that is slow. Basically gzip. Gzip saves time of spinning disks (not RAID) but is level pegging with SSD. The space saved is worth it anyway.
Compression comes in to its own when youāre dealing with laptop spinning disks, hopefully a dying breed but awfully slow nonetheless.
Iāve considered multithreading loading code a number of times but the headache isnāt worth it for the gains. For a start there is usually a dependency graph of resources that needs to be calculated, which isnāt trivial, and then youāve got to feed it all into a thread pool and then collect the final results in a single thread at the end to send to OpenGL etc etc. Obviously a bit different with Vulkan but thatās all cutting edge anyway.
Cas
I started learning Lƶve2D for Lua, and I think I fell in love (pun not intended)