[QUOTE=Natrox;36014897]I am working on my own implementation of a vector with very basic functionality;
[img]http://i48.tinypic.com/hva34g.png[/img][/QUOTE]
Stuff like this make me feel like a noob using the std datatypes. That and the memory management that you are supposed to write by yourself to make it fast.
[QUOTE=AlienCat;36016269]Stuff like this make me feel like a noob using the std datatypes. That and the memory management that you are supposed to write by yourself to make it fast.[/QUOTE]
The way I see it, you don't need to worry about it until it becomes a concern (and I use "concern" loosely). Granted, you should only use data types appropriate to a situation and avoid things like inserting and removing elements from the middle of a vector. If you want to be good at a specific thing, though, all you need to do is [url=http://stackoverflow.com/questions/826569/compelling-examples-of-custom-c-stl-allocators]start[/url] reading up on it and start doing it. You could call this studying, and if one is serious about programming, I don't see how one could ever stop studying.
There is just so much out there to learn...kind of gets me excited :v:
Remember: chances are that there is probably an allocator already written for the good majority of things you want to do. Already tested, already vetted.
[QUOTE=Within;36014918]Alright, second attempt for my CAPTCHA stuff.
I switched the z-order so obfuscation is drawn after the string and now has a random color [I]which is already present[/I] in one of the letters. All the colors are in an array so it's just picking one at random.
[B]Square obfuscation:[/B]
[IMG]http://i.imgur.com/w8qHq.png[/IMG]
[B]Circle obfuscation:[/B]
[IMG]http://i.imgur.com/loXfP.png[/IMG]
[B]Line obfuscation:[/B]
[IMG]http://i.imgur.com/xTL5v.png[/IMG]
[B]Line obfuscation, SingleBitPerPixel text rendering and no AntiAlias for obfuscation[/B]
[IMG]http://i.imgur.com/WP0Qx.png[/IMG]
[B]Same as above, but monochrome string and obfuscation[/B]
[IMG]http://i.imgur.com/j0UlE.png[/IMG]
Anything on these? I'm not entirely sure how to improve beyond this, critique is very welcome.
[editline]19th May 2012[/editline]
[URL="http://www.alldatasheet.com"]www.alldatasheet.com[/URL]
[U]Very[/U] helpful resource.[/QUOTE]
I think you're going about this the wrong way. Entering random strings of letters is easy for a computer and hard for a human.
Asking questions which require moderate intelligence are probably far more effective and harder for programmers to write a 5 minute script to crack.
Have some pictures which are cartoon drawings of animals, or shapes, or well known company logos.The user might not guess the first result, but give them 3 chances and if they get one they you can assume to the best of your ability they're human.
You could also have a picture, and require the user to click on a certain object in the picture. This easily starts to become really hard for the computer to complete without guessing.
Within: You should read up on [url=http://www.google.com/recaptcha/captcha]recaptcha[/url]. They pretty much outline the requirements and common pitfalls for captchas.
Heads up for any of you who are making minecraft software.
The next version uses RC4 across the whole stream
(I'm giving up on all of my tools now)
[url]http://mc.kev009.com/Protocol_Encryption[/url]
Calling functions.
[CODE]
Test #3:
> (function test ()
10)
define i64 @test0(){
%tmp.version6 = alloca i64
store i64 10, i64* %tmp.version6
%res.version8 = load i64* %tmp.version6
ret i64 %res.version8
}
Test #4:
> (test)
%res.version9 = call ccc i64 @test0()
[/CODE]
[QUOTE=Dotmister;36016605]Have some pictures which are cartoon drawings of animals, or shapes, or well known company logos.The user might not guess the first result, but give them 3 chances and if they get one they you can assume to the best of your ability they're human.[/QUOTE]
Google's reverse image search already does that, though. Upload an image and it will suggest a search term most of the times.
[QUOTE=benjojo;36016776]Heads up for any of you who are making minecraft software.
The next version uses RC4 across the whole stream
(I'm giving up on all of my tools now)
[url]http://mc.kev009.com/Protocol_Encryption[/url][/QUOTE]
Why the fuck is mojang adding encryption to the protocol, when they could spend the time optimising it and making it less laggy? (aka use udp and not tcp)
[QUOTE=horsedrowner;36016883]Google's reverse image search already does that, though. Upload an image and it will suggest a search term most of the times.[/QUOTE]
That won't work if you create original images
[QUOTE=horsedrowner;36016883]Google's reverse image search already does that, though. Upload an image and it will suggest a search term most of the times.[/QUOTE]
I'm pretty sure it works through internet picture-word associations; if you take a picture of your cat and then reverse image search it, it's not going to figure out it's a cat.
[QUOTE=benjojo;36016776]Heads up for any of you who are making minecraft software.
The next version uses RC4 across the whole stream
(I'm giving up on all of my tools now)
[url]http://mc.kev009.com/Protocol_Encryption[/url][/QUOTE]
Ahahaha.
So I talked to evilseth and I asked why and he stated it was to stop MITM attacks...
Then someone pointed out that does not protect against MITM if you actually look at how the key exchange is done.
So while trying to make my OpenGL non-deprecated I messed up my shaders, creating quite an interesting art style:
[img]http://i.imgur.com/LB12B.png[/img]
[img]http://i.imgur.com/eyIXZ.png[/img]
[QUOTE=thomasfn;36017066]Why the fuck is mojang adding encryption to the protocol, when they could spend the time optimising it and making it less laggy? (aka use udp and not tcp)[/QUOTE]
Holy shit minecraft uses TCP over UDP ?? When learning about networking, the [b]first[/b] thing you learn is that you should use TCP only when you need to make sure that the user received all the packets in the right order... however you [b]must[/b] be aware that the process is much slower than UDP. I mean I knew that minecraft was poorly written but that's just a huge design flaw, no wonder it's so slow :v:
[IMG_THUMB]http://i.imgur.com/vMVgR.png[/IMG_THUMB]
I've hacked Gwen.NET over to Xbox 360 and Windows Phone 7. This does however make it incompatible since I've had to switch from System.Drawing.Color to Microsoft.Xna.Framework.Color. I'll be putting this up on my repo soonish, it's very hacky currently :)
Turb added some basic graphics functions to his operating system a while ago (the bouncing ball), but he wanted something a bit more exciting. Last Wednesday he asked me if I could write a graphics demo for JSOS and I proposed to implement OpenGL 1.1 for him. He said that would take a lot of work and he just needed a simple 3D demo with functions like [i]drawCube()[/i].
Since we all know how much I love OpenGL, I did it anyway and implemented just enough of the OpenGL 1.1 spec to do something useful. I implemented the entire graphics pipeline in software in Javascript and it was a [url=https://github.com/Overv/JSGL]great success[/url]. Because it's a lot easier to debug Javascript in a browser, I developed it using the HTML5 canvas to visualize the color buffer as seen below.
[url=http://dev.vertinode.nl/jsgl/][img]http://puu.sh/vBHp[/img][/url]
My JSGL (Javascript Graphics Library) provides [i]gl.readPixels()[/i] to read back data from either the color buffer or the depth buffer. It then pushes that data through to the canvas by calling [i]putImageData()[/i] on the 2D context.
The vertex processing code makes use of the [i]mat4[/i] functions in the [url=https://github.com/toji/gl-matrix]gl-matrix[/url] library to apply the transformations. I found it kind of pointless to implement these functions myself, because that library is already highly optimized for that purpose.
The rasterizer is based completely on my own code, with inspiration from Bresenham's line algorithm, [url=http://courses.cms.caltech.edu/cs171/barycentric.pdf]this paper on barycentric coordinates[/url] and [url=http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.3.211&rep=rep1&type=pdf]this paper on perspective correct interpolation[/url].
I based all of the other code on my experience with OpenGL itself and used the OpenGL 1.1 Specification to make sure everything was implemented correct. The implementation is not complete (e.g. functions and enum values are missing), but the stuff that is supported stays true to the original specification, like when errors should be thrown.
Yesterday I started working on porting the code to JSOS, which proved to be a little more difficult than I anticipated. The code required little to no alteration to work, but I had to change some things in Turb's driver code to be able to draw pixels to the display. I also had to add a new pixel format mode to [i]gl.readPixels()[/i], [i]GL_UNSIGNED_BYTE_2_3_3[/i]. It's because his operating system currently allows only 1 byte per pixel with a bit layout of RRGGGBBB. The HTML5 canvas worked with RGBA bytes, which is what the implementation was originally limited to.
I also found that JSOS (or the JS compiler) didn't have an implementation for the [i]!=[/i] operator, [i]Math.max[/i], [i]Math.min[/i], [i]Math.tan[/i] and [i]Date[/i] yet and I had to work around that by implementing them myself. The lack of support for the [i]!=[/i] operator was only because it's better to use the [i]!==[/i] operator, so that was a simple Find & Replace job.
After all this tweaking today, I was finally greeted by a working render! Here is the output of the program [i]gltest[/i] running on JSOS in VirtualBox:
[img]http://puu.sh/vBQd[/img]
I haven't managed to get it to render more than one frame yet (in a timely fashion), but at least now JSOS has some working OpenGL bindings!
Oh shit.
Now put SDL on it
[QUOTE=Overv;36017997]Turb added some basic graphics functions to his operating system a while ago (the bouncing ball), but he wanted something a bit more exciting. Last Wednesday he asked me if I could write a graphics demo for JSOS and I proposed to implement OpenGL 1.1 for him. He said that would take a lot of work and he just needed a simple 3D demo with functions like [i]drawCube()[/i].
Since we all know how much I love OpenGL, I did it anyway and implemented just enough of the OpenGL 1.1 spec to do something useful. I implemented the entire graphics pipeline in software in Javascript and it was a [url=https://github.com/Overv/JSGL]great success[/url]. Because it's a lot easier to debug Javascript in a browser, I developed it using the HTML5 canvas to visualize the color buffer as seen below.
[url=http://dev.vertinode.nl/jsgl/][img]http://puu.sh/vBHp[/img][/url]
My JSGL (Javascript Graphics Library) provides [i]gl.readPixels()[/i] to read back data from either the color buffer or the depth buffer. It then pushes that data through to the canvas by calling [i]putImageData()[/i] on the 2D context.
The vertex processing code makes use of the [i]mat4[/i] functions in the [url=https://github.com/toji/gl-matrix]gl-matrix[/url] library to apply the transformations. I found it kind of pointless to implement these functions myself, because that library is already highly optimized for that purpose.
The rasterizer is based completely on my own code, with inspiration from Bresenham's line algorithm, [url=http://courses.cms.caltech.edu/cs171/barycentric.pdf]this paper on barycentric coordinates[/url] and [url=http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.3.211&rep=rep1&type=pdf]this paper on perspective correct interpolation[/url].
I based all of the other code on my experience with OpenGL itself and used the OpenGL 1.1 Specification to make sure everything was implemented correct. The implementation is not complete (e.g. functions and enum values are missing), but the stuff that is supported stays true to the original specification, like when errors should be thrown.
Yesterday I started working on porting the code to JSOS, which proved to be a little more difficult than I anticipated. The code required little to no alteration to work, but I had to change some things in Turb's driver code to be able to draw pixels to the display. I also had to add a new pixel format mode to [i]gl.readPixels()[/i], [i]GL_UNSIGNED_BYTE_2_3_3[/i]. It's because his operating system currently allows only 1 byte per pixel with a bit layout of RRGGGBBB. The HTML5 canvas worked with RGBA bytes, which is what the implementation was originally limited to.
I also found that JSOS (or the JS compiler) didn't have an implementation for the [i]!=[/i] operator, [i]Math.max[/i], [i]Math.min[/i], [i]Math.tan[/i] and [i]Date[/i] yet and I had to work around that by implementing them myself. The lack of support for the [i]!=[/i] operator was only because it's better to use the [i]!==[/i] operator, so that was a simple Find & Replace job.
After all this tweaking today, I was finally greeted by a working render! Here is the output of the program [i]gltest[/i] running on JSOS in VirtualBox:
[img]http://puu.sh/vBQd[/img]
I haven't managed to get it to render more than one frame yet (in a timely fashion), but at least now JSOS has some working OpenGL bindings![/QUOTE]
This is amazing! I can't wait to see things like OpenCL working on this thing too! It's amazing!
[QUOTE=T3hGamerDK;36018277]This is amazing! I can't wait to see things like OpenCL working on this thing too! It's amazing![/QUOTE]
This is purely software based, there won't be any hardware acceleration.
I finally managed to "fix" lighting in my terrain generator.
[img]http://puu.sh/vChW[/img]
The method I used for calculating normals may have been... flawed.
[QUOTE=Robber;36018505]This is purely software based, there won't be any hardware acceleration.[/QUOTE]
:(
[img]http://puu.sh/vCO6[/img]
Close enough. I wasn't expecting to have to implement the image decompression algorithm myself but there you go.
[QUOTE=Overv;36017997][img]http://puu.sh/vBQd[/img][/QUOTE]
[QUOTE=Robber;36018505]This is purely software based, there won't be any hardware acceleration.[/QUOTE]
this accelerates my hardware [img]http://i.somethingawful.com/forumsystem/emoticons/emot-smug.gif[/img]
[QUOTE=Ziks;36018950][img]http://puu.sh/vCO6[/img]
Close enough. I wasn't expecting to have to implement the image decompression algorithm myself but there you go.[/QUOTE]
Are you reverse engineering the format or are you usign something else? If something else do tell what!
[IMG]http://i.imgur.com/AwuQf.png[/IMG]
Added cursors via GWEN themes since Xbox's and Windows Phone's don't have a cursor. GWEN.NET should now run on pretty much anything that supports XNA although I haven't added proper touch support yet, I think that'll be my job for tomorrow. Also excuse the crap cursors but I could find any sets that don't suck so for an example I ripped those from [url]http://qt-project.org/doc/qt-4.8/qcursor.html[/url] but they all have crappy white outlines, and aren't properly aligned, GRR.
[QUOTE=Map in a box;36019316]Are you reverse engineering the format or are you usign something else? If something else do tell what![/QUOTE]
There's bits and pieces of documentation around, like [url=http://www.chronetal.co.uk/gta/index.php?page=dff]this[/url] for models and [url=http://www.gtamodding.com/index.php?title=IMG_archive]this[/url] for the main game archives, although not much is explained and there are quite a lot of gaps.
[QUOTE=ryandaniels;36017099]I'm pretty sure it works through internet picture-word associations; if you take a picture of your cat and then reverse image search it, it's not going to figure out it's a cat.[/QUOTE]
"What color eyes does this cat have?"
[QUOTE=Overv;36017997]Turb added some basic graphics functions to his operating system a while ago (the bouncing ball), but he wanted something a bit more exciting. Last Wednesday he asked me if I could write a graphics demo for JSOS and I proposed to implement OpenGL 1.1 for him. He said that would take a lot of work and he just needed a simple 3D demo with functions like [i]drawCube()[/i].
Since we all know how much I love OpenGL, I did it anyway and implemented just enough of the OpenGL 1.1 spec to do something useful. I implemented the entire graphics pipeline in software in Javascript and it was a [url=https://github.com/Overv/JSGL]great success[/url]. Because it's a lot easier to debug Javascript in a browser, I developed it using the HTML5 canvas to visualize the color buffer as seen below.
[url=http://dev.vertinode.nl/jsgl/][img]http://puu.sh/vBHp[/img][/url]
My JSGL (Javascript Graphics Library) provides [i]gl.readPixels()[/i] to read back data from either the color buffer or the depth buffer. It then pushes that data through to the canvas by calling [i]putImageData()[/i] on the 2D context.
The vertex processing code makes use of the [i]mat4[/i] functions in the [url=https://github.com/toji/gl-matrix]gl-matrix[/url] library to apply the transformations. I found it kind of pointless to implement these functions myself, because that library is already highly optimized for that purpose.
The rasterizer is based completely on my own code, with inspiration from Bresenham's line algorithm, [url=http://courses.cms.caltech.edu/cs171/barycentric.pdf]this paper on barycentric coordinates[/url] and [url=http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.3.211&rep=rep1&type=pdf]this paper on perspective correct interpolation[/url].
I based all of the other code on my experience with OpenGL itself and used the OpenGL 1.1 Specification to make sure everything was implemented correct. The implementation is not complete (e.g. functions and enum values are missing), but the stuff that is supported stays true to the original specification, like when errors should be thrown.
Yesterday I started working on porting the code to JSOS, which proved to be a little more difficult than I anticipated. The code required little to no alteration to work, but I had to change some things in Turb's driver code to be able to draw pixels to the display. I also had to add a new pixel format mode to [i]gl.readPixels()[/i], [i]GL_UNSIGNED_BYTE_2_3_3[/i]. It's because his operating system currently allows only 1 byte per pixel with a bit layout of RRGGGBBB. The HTML5 canvas worked with RGBA bytes, which is what the implementation was originally limited to.
I also found that JSOS (or the JS compiler) didn't have an implementation for the [i]!=[/i] operator, [i]Math.max[/i], [i]Math.min[/i], [i]Math.tan[/i] and [i]Date[/i] yet and I had to work around that by implementing them myself. The lack of support for the [i]!=[/i] operator was only because it's better to use the [i]!==[/i] operator, so that was a simple Find & Replace job.
After all this tweaking today, I was finally greeted by a working render! Here is the output of the program [i]gltest[/i] running on JSOS in VirtualBox:
[img]http://puu.sh/vBQd[/img]
I haven't managed to get it to render more than one frame yet (in a timely fashion), but at least now JSOS has some working OpenGL bindings![/QUOTE]
Now you should make a Minecraft clone the main GUI of JSOS
[QUOTE=ben1066;36019589][IMG]http://i.imgur.com/AwuQf.png[/IMG]
Added cursors via GWEN themes since Xbox's and Windows Phone's don't have a cursor. GWEN.NET should now run on pretty much anything that supports XNA although I haven't added proper touch support yet, I think that'll be my job for tomorrow. Also excuse the crap cursors but I could find any sets that don't suck so for an example I ripped those from [url]http://qt-project.org/doc/qt-4.8/qcursor.html[/url] but they all have crappy white outlines, and aren't properly aligned, GRR.[/QUOTE]
Just one word : NICE !
Sorry, you need to Log In to post a reply to this thread.