[QUOTE=Conna;39419049]First five tutorial levels of my untitled game. Made the engine in C++ and binding Lua for scripting. This is alpha footage so yeah there's some placeholder art, sounds and visual effects. There's also lots of bugs too, and sprinting is disabled that's why I'm walking everywhere.
Also please excuse the orange tint of the video, I'm not entirely sure why that's happening, it doesn't look like that in-game.
[media]http://www.youtube.com/watch?v=djI69YQSYdo&hd=1[/media]
Please note that these are just the tutorial levels which is why they're ridiculously easy, and why there's only one enemy type/no bosses.[/QUOTE]
Pretty awesome though I would make the flashlight reach further, by the time you can see the enemy its way too close to you
Figured out how Lego Racers stores timings for subtitle and sound events during cutscenes.
Note: I'm not rendering the cutscene myself (yet), that's just a fraps capture from the actual game, overlaid on my timeline renderer.
[video=youtube;y_sbL5ceZoA]http://www.youtube.com/watch?v=y_sbL5ceZoA[/video]
Edit: I have no idea what the two entries marked "Dtube" actually do.
Working on Letit Flow some more.
Recycled the debug red/blue circles into more fanciful in/out "sockets". Among other things, I replaced the lame green line connection with a line that gradients from green to red, parent to child. That is to say, the line starts out green as it comes out the parent, and as it plugs into the child, the line turns red. I also offset the location of the in/out sockets: Output sockets are shifted 30% of the smaller dimension one way, input sockets the other. Automatically snaps correctly as boxes move.
Decided to stress-test it. This is 12 boxes, with each box connected to every other box in two ways: parent-child and child-parent. Basically every box is every other box's parent and child both.
Lines are 12 segments each, so that means this is effectively drawing 24*12, or 288, lines. In addition to the boxes, text, and in/out icons. Also note that it caps at 60fps.
[t]https://dl.dropbox.com/u/8416055/LetItFlow_WIP_001.jpg[/t]
Moving any particular box in this situation causes no more than 1- or 2- frame drop, because I only calculate the positions of the intermediary line points when the connections update, which only occurs when a connection is created or when a box is moved. Color interpolarity is only calculated once, on program load, because the number of segments - and therefore the interpolated color values for each segment - does not change.
Once I add infinite canvas space, I will make a new video showing off this and other features.
[editline]Fish[/editline]
Actually I think my math is wrong. Each box draws 24 lines. So... 24^2 * 12? Can someone correct me here?
The problem with instacode is that it doesn't separate 'pixels' into RGB for added realism, also when the text is large each 'pixel' manages to contain loads of actual pixels because they just overlay a black grid. It's really poorly done imo.
[QUOTE=sambooo;39419870]The problem with instacode is that it doesn't separate 'pixels' into RGB for added realism, also when the text is large each 'pixel' manages to contain loads of actual pixels because they just overlay a black grid. It's really poorly done imo.[/QUOTE]
It's meant to be [i]artistic[/i].
[QUOTE=DrLuckyLuke;39417553]are u fucking reatred? bitbang > spi > you#re mom > i2c[/QUOTE]
[sp]i banged urs[/sp]
In all seriousness though, just because it's efficient doesn't mean it's best.
Not to mention that it doesn't work that well with ADC which is used extensively in my line of work. You can't bitbang a precision thermostat and expect it to work.
[QUOTE=TrafficMan;39419480][b][i]CLIPS[/b][/i][/QUOTE]
i think it should stay that way just to bother people
also make ammo "shells" or something of the sort instead
[QUOTE=sambooo;39419870]The problem with instacode is that it doesn't separate 'pixels' into RGB for added realism.[/QUOTE]
Pixels are already RGB, man.
[i]its sorta how that has always worked[/i].
[QUOTE=Topgamer7;39418812]TBH, you guys are posting more about what you are actually working on then usual, just because don't like hipster code screenshots, doesn't mean they aren't contributing.[/QUOTE]
A dark angled screenshot of some arbitrary portion of your code isn't much of a contribution, spamming the thread with these images isn't an improvement.
[QUOTE=Conna;39419049]First five tutorial levels of my untitled game. Made the engine in C++ and binding Lua for scripting. This is alpha footage so yeah there's some placeholder art, sounds and visual effects. There's also lots of bugs too, and sprinting is disabled that's why I'm walking everywhere.
Also please excuse the orange tint of the video, I'm not entirely sure why that's happening, it doesn't look like that in-game.
[media]http://www.youtube.com/watch?v=djI69YQSYdo&hd=1[/media]
Please note that these are just the tutorial levels which is why they're ridiculously easy, and why there's only one enemy type/no bosses.[/QUOTE]
This looks cool. Are you using any specific API? SFML/SDL etc?
[QUOTE=origamiguy;39419371]Figured out how Lego Racers stores timings for subtitle and sound events during cutscenes.
Note: I'm not rendering the cutscene myself (yet), that's just a fraps capture from the actual game, overlaid on my timeline renderer.
[video=youtube;y_sbL5ceZoA]http://www.youtube.com/watch?v=y_sbL5ceZoA[/video]
Edit: I have no idea what the two entries marked "Dtube" actually do.[/QUOTE]
I would love to see this become an open source port of Lego Racers.
Looks fun
[img]http://instacode.linology.info/file/43640[/img]
Ok, stop with the goddamn instacode, it's getting annoying.
Need to add saving and loading. Not really sure what to do after that.
[media]http://www.youtube.com/watch?v=DF9mnL7H11I&feature=youtu.be[/media]
So, by some not particularly exciting or clever optimisations, my test scene that i use has gone from 17 ms/frame, to 12 ms/frame. Woo. It pretty much involved using a slightly worse depth check (so, potentially flickering pixels but in practice its pretty much the same it was before) so that less time is wasted trying to make sure as much as possible without atomic operations is correct. The normal buffer gets corrected in the second half of the deferred part of the engine anyway, so its not too much of a problem
For reference
[IMG]https://dl.dropbox.com/u/33076954/New/TFiltering/Notparticularlyclever.PNG[/IMG]
Removing all memory/accuracy checking only brings frametime down to 11 ms/frame. That means that optimisations regarding that specific area are pretty much as good as they're going to get
For possibly the only reasonably legitimate use of instacode so far, the piece of code that handles this section is much clearer than any crap explanation i can give without it:
[IMG]http://instacode.linology.info/file/44048[/IMG]
Essentially, a few threads at once will be competing for ft, that is the current memory cell which stores the depth of the pixel. fn, and ftm are the normal, and texture maps respectively
The code loops until the value stored at *ft is the depth of the current pixel - that is to say, at some point in time we successfully wrote the depth value to the buffer, and we're acceptably (but not 100%) confident that the depth value written is correct
On a technical note, this is complicated by the fact that the nvidia 6 series introduced cached global memory access - you have to declare the pointers to global memory as volatile so that it doesn't cache the access (and so invalidate the method above, or at least make it much less accurate)
The speedup comes from no longer making sure that the normal, and vt coordinates are successfully written to their buffers accurately, along with depth. Because a small error in the normal map looks weird as crap, error correction is performed on the normal buffer based on the surrounding normals. Because, additionally, errors in the normal maps are only obvious if they are significant, its pretty easy to find dodgy normals and correct them. This could be an issue in certain cases, but its solved the issue for quite a long time now so im reasonably confident that its acceptable. The vt buffer doesn't seem to error (?) as much, or at least errors are less obvious, so for the moment no error correction is performed. Its pretty quick to do though, so I will write it in in the future. I will additionally do the same if I need a level of accuracy in the depth buffer
So there you have it. Lossy/mildly inaccurate deferred rendering!
I finally got one of the best parts of OpenGL working correctly and in a way that lets me dynamically use them - shaders!
[thumb]http://i.imgur.com/80zwezF.png[/thumb]
Nothing advanced yet, but it follows the usual traits of the rest of the game - so I can do something like ShaderManager.getShaderProgram("/shader/test").enable(); - which would enable the shader (or load it first if need be) before drawing quads.
[QUOTE=luck_or_loss;39422804]Not low level enough
[thumb]https://dl.dropbox.com/u/25698984/ItsNotMachineCode.png[/thumb]
[url]http://www.random.org/cgi-bin/randbyte?nbytes=1000&format=b[/url][/QUOTE]
But that's not machine code.
[QUOTE=_Undefined;39418489]Out of interest, what are you using the radiation data from that xml feed for exactly?[/QUOTE]
I'm making an app that uses publicly available radiation readings from different stations around Norway, and tells the user the levels at his or her nearest station. It's not really that useful, but I found the data kind of randomly, and thought that it was something I could make.
[img]http://puu.sh/1VhJD[/img]
I had a discussion with a guy from the web development subforum, and we decided that this was the best design. For reference, here's the same design, just with Holo.Dark:
[img]http://puu.sh/1VhLQ[/img]
[editline]31st January 2013[/editline]
I just realised that the button for the about page disappears in the light design...
[QUOTE=Larikang;39421739]I would love to see this become an open source port of Lego Racers.[/QUOTE]
I don't know about that, but I'm intending to release my documentation of the file formats at the very least.
[QUOTE=Gulen;39423747]I'm making an app that uses publicly available radiation readings from different stations around Norway, and tells the user the levels at his or her nearest station. It's not really that useful, but I found the data kind of randomly, and thought that it was something I could make.
-snip-
I had a discussion with a guy from the web development subforum, and we decided that this was the best design. For reference, here's the same design, just with Holo.Dark:
-snip-
[editline]31st January 2013[/editline]
I just realised that the button for the about page disappears in the light design...[/QUOTE]
If you want to be extra cool you should use [url=http://classes.soe.ucsc.edu/cmps160/Fall10/resources/barycentricInterpolation.pdf]barycentric interpolation[/url], take the nearest 3 stations and interpolate the radiation for your current position based on the radiation levels at the stations.
(also make it work in Ukraine)
Posted this in the wrong thread.. here it is in the right one.
You know they're a cunt when..
[img]http://puu.sh/1Vi6R[/img]
[img]http://i.imgur.com/1PkeDzp.png[/img][img]http://i.imgur.com/EwB1TcO.png[/img][img]http://i.imgur.com/b0Re1wL.png[/img]
[img]http://i.imgur.com/MmlUZ.gif[/img]
[editline]31st January 2013[/editline]
[QUOTE=garry;39424552]You know they're a cunt when..
[img]http://puu.sh/1Vi6R[/img][/QUOTE]
You know who's a cunt?
[QUOTE=Drak_Thing;39421236]This looks cool. Are you using any specific API? SFML/SDL etc?[/QUOTE]
I'm using ClanLib for rendering and input, it's not the best and I'm likely to switch at some point or handle it myself.
[QUOTE=Lexic]You know who's a cunt?[/QUOTE]
Cunta? ;)
[QUOTE=Dlaor-guy;39424470]If you want to be extra cool you should use [url=http://classes.soe.ucsc.edu/cmps160/Fall10/resources/barycentricInterpolation.pdf]barycentric interpolation[/url], take the nearest 3 stations and interpolate the radiation for your current position based on the radiation levels at the stations.
(also make it work in Ukraine)[/QUOTE]
I'll have a look at that document and see if I can understand any of it. At first I think I'll stick to the closest station, as that seems difficult enough for me.
[editline]31st January 2013[/editline]
What's that big "E" symbol, though? I've seen it before, but I've never understood what it meant
[QUOTE=Gulen;39424679]What's that big "E" symbol, though? I've seen it before, but I've never understood what it meant[/QUOTE]
Usually it means a sum. It's basically a for loop that goes from the bottom value to the value on top of it and sums up all the members.
[editline]31st January 2013[/editline]
Sigma i lambda i = 1 probably means the sum of all lambdas is 1.
[QUOTE=Gulen;39424679]I'll have a look at that document and see if I can understand any of it. At first I think I'll stick to the closest station, as that seems difficult enough for me.
[editline]31st January 2013[/editline]
What's that big "E" symbol, though? I've seen it before, but I've never understood what it meant[/QUOTE]
With Barycentric coordinates, the three resultant values (a,b,c for example) are all between 0 and 1 if the point being tested is inside the triangle. The sum of the three values are always equal to 1, and so you can cheat the calculation by only calculating the first two coords (a,b) and then finding the third c = 1 - (a+b) .
Sorry, you need to Log In to post a reply to this thread.
