• What are you working on? January 2012
    3,401 replies, posted
[QUOTE=Kopimi;34188023][media]http://www.youtube.com/watch?v=N8plefUTbrM&feature=youtu.be[/media] i finished my 3d cam node and implemented directinput8 in a "kopinput" class so far its working really well so i think ill move on to obj loader[/QUOTE] You're almost as bad as Nigey Nige.
[QUOTE=Yogurt;34188432]You're almost as bad as Nigey Nige.[/QUOTE] ?? why and does this mean you're challenging me to a fight
[QUOTE=Kopimi;34188471]?? why and does this mean you're challenging me to a fight[/QUOTE] [img]http://i.imgur.com/aUkyR.png[/img]
are you making fun of my graphics or the fact that i'm releasing my engine under the name "Kopimi's Koptastic Kopimatic Kame Engine: Kopimi Edition, By Kopimi" because either way i dont care, bud
[QUOTE=Kopimi;34188559]are you making fun of my graphics or the fact that i'm releasing my engine under the name "Kopimi's Koptastic Kopimatic Kame Engine: Kopimi Edition, By Kopimi" because either way i dont care, bud[/QUOTE] the latter, pal
[QUOTE=ROBO_DONUT;34183535]I honestly think the 'future' of computing graphics is raytracing point cloud or voxel data in a hierarchical manner with dedicated hardware. I think Intel was researching this, and they definitely have the expertise and infrastructure to make it happen. They're probably in a better position than Nvidia even because CPU architecture is better suited for it than GPU architecture. (See below).[/QUOTE] I couldn't agree with you more. I did a lot of research and even made an extremely minimal (and incorrect) raytracer a few threads back. During my research, I found a few articles about raytracing by Daniel Pohl, a guy who rewrote Quake 3 and 4 to use a raytracer for rendering. Here's a little graph: [img]http://pcper.com/images/reviews/506/logvslin.jpg[/img] The Articles: [url]http://www.pcper.com/reviews/Graphics-Cards/Ray-Tracing-and-Gaming-Quake-4-Ray-Traced-Project/[/url] [url]http://www.pcper.com/reviews/Processors/Ray-Tracing-and-Gaming-One-Year-Later/[/url] Basically, the speed of raytracing scales immensely with an increased number of cores, and the ratio of CPU time to triangles is logarithmic. Compared to the linear nature of rasterization, once processors are fast enough, raytracing will be faster than polygons. With a bit more power, raytracing will be able to render a nearly infinite amount of triangles with time to spare. [editline]12th January 2012[/editline] By the way, the Author got hired by Intel be a head reasearcher or something for their work on raytracing. Also on the topic or transistor size I read somewhere that Intel was going to be stacking them upwards or something like that
[QUOTE=ZenX2;34188813]able to render a [b]nearly infinite[/b] amount of triangles with time to spare.[/QUOTE]
[QUOTE=Kamshak;34181518]isn't CUDA/OpenCL very well suited for these kinds of massively parallel operations? Now i'd really like to look into ray tracing and see if this can give a noticable performance boost[/QUOTE] From what I can tell the demo garry posted is already running in a shader.
[QUOTE=swift and shift;34189499][/QUOTE] Okay, not infinite, but still quite a bit. The writer of those articles replaced the 2 triangle walls in Quake with detailed 5,000 triangle walls and only had 1/4 fps drop.
[QUOTE=swift and shift;34189499]:words:[/QUOTE] I don't think you understand how logarithms work. The more you throw at a logarithmic algorithm, the better it performs. At some point, when you have enough power and a raytracer that has logarithmic time complexity, you'll be able to dump so much data into it that there's no [i]practical[/i] limit in terms of computing time constraints. The only limit, then, becomes the amount of memory and hard disk space your machine has. Because you still have to store all that crap.
[QUOTE=ROBO_DONUT;34189919]I don't think you understand how logarithms work. The more you throw at a logarithmic algorithm, the better it performs. At some point, when you have enough power and a raytracer that has logarithmic time complexity, you'll be able to dump so much data into it that there's no [i]practical[/i] limit in terms of computing time constraints. The only limit, then, becomes the amount of memory and hard disk space your machine has. Because you still have to store all that crap.[/QUOTE] i understand exactly how logarithms work. my point is: what makes 'nearly infinite' any different to 'even more nearly infinite'?
[QUOTE=swift and shift;34189968]i understand exactly how logarithms work. my point is: what makes 'nearly infinite' any different to 'even more nearly infinite'?[/QUOTE] Nothing
[QUOTE=swift and shift;34189968]i understand exactly how logarithms work. my point is: what makes 'nearly infinite' any different to 'even more nearly infinite'?[/QUOTE] Practically infinite(=nearly infinite) means within reasonable numbers. Nobody will ever try to render 10^100 polygons. More than that would be mathematical infinity which would also include 10^10^100 and more.
By "nearly" I meant "as close as is possible by the current laws of physics and other parts of the technology" [editline]13th January 2012[/editline] I still really want to make a game engine based purely on spheres Like, models are made up of spheres of single colors, so there's no textures, and they all have physics and stuff But that's not gonna be possible for a while :C
[QUOTE=ZenX2;34190040]Nothing[/QUOTE] exactly
Pedant. [QUOTE=ZenX2;34190050]Like, models are made up of spheres of single colors, so there's no textures, and they all have physics and stuff But that's not gonna be possible for a while :C[/QUOTE] That won't ever happen. You can render a static scene in O(log n) time, but with n [i]dynamic[/i] particles, it's still going to take O(n log n) time because you need to do collision detection and update the position in the tree.
[QUOTE=swift and shift;34190083]exactly[/QUOTE] Stop being pedantic; we all understood that he meant "theoretically unlimited but practically constrained."
Despite all the work I've done with OpenGL, I didn't know that there were built-in point sprites, so I've been creating two triangles for every character in my font rendering code. Now I get to reduce my buffer size from 64 bytes per character + 24 bytes for the indices to 8 bytes per character + 0 bytes for indices. (order doesn't matter now!) [editline]a[/editline] Actually it would be 16 bytes per character, I still need to pass in the center of character's texcoord location. That's still less than 20% of the original amount of data which is amazing.
[QUOTE=calzoneman;34183895]Thought I'd take a stab at Chip-8: [IMG]http://i.imgur.com/lsAiY.png[/IMG] It can also disassemble, although it's mostly guessing on where the code ends since Chip8 ROMs can just throw data wherever the fuck they want (right now it assumes it's reached EOC if it reaches a JP that jumps to its own address or if it finds an unrecognized opcode) [IMG]http://i.imgur.com/ZUHMU.png[/IMG] Next up: Assembling![/QUOTE] I made once an emulator ages ago, just compiled it right now to throw a screenshot :D [img]http://dl.dropbox.com/u/29407915/chip8.png[/img] Theres no screen, so it probably looks more like a debugger lol I never finished it tho.
working on my php obfuscator, ran my [b]entire[/b] installation of MyBB through it and it seems to work. I committed the resulting code to a git repo: [url]https://github.com/charliesome/obfuscated-mybb[/url] Here's a sample: [img]http://i.imgur.com/rlUei.png[/img] Feel free to peruse the rest of the repo too!
[QUOTE=swift and shift;34190869]working on my php obfuscator, ran my [b]entire[/b] installation of MyBB through it and it seems to work. I committed the resulting code to a git repo: [url]https://github.com/charliesome/obfuscated-mybb[/url] Here's a sample: [img]http://i.imgur.com/rlUei.png[/img] Feel free to peruse the rest of the repo too![/QUOTE] Looks highly inefficient if you have a bigger website with plenty traffic this might be a bottleneck
[QUOTE=swift and shift;34190869]working on my php obfuscator, ran my [b]entire[/b] installation of MyBB through it and it seems to work. I committed the resulting code to a git repo: [url]https://github.com/charliesome/obfuscated-mybb[/url] Here's a sample: [img]http://i.imgur.com/rlUei.png[/img] Feel free to peruse the rest of the repo too![/QUOTE] Did you try benchmarking the obfuscated code versus the unobfuscated version?
ROBO_DONUT, how do you think quantum computing will influence the future of CPUs and GPUs? Would it suit the current architecture of GPUs because of its highly efficient parallel computing capabilities or would we have to conceive entire new architectures? And how can it be used for CPUs, if at all?
[QUOTE=Robber;34191060]Did you try benchmarking the obfuscated code versus the unobfuscated version?[/QUOTE] fib(30) regular php: 500ms obfuscated php: 11 seconds [editline]13th January 2012[/editline] [QUOTE=Zeh Matt;34190891]Looks highly inefficient if you have a bigger website with plenty traffic this might be a bottleneck[/QUOTE] if you have a large website, you're not going to be obfuscating your own code
What are you gonna use?
[QUOTE=garry;34191372]What are you gonna use?[/QUOTE] [url=http://en.wikipedia.org/wiki/Jaxer#Aptana_Jaxer]Jaxer[/url] [sp]I have no idea weather jaxer is fast or not, I just like it.[/sp]
[QUOTE=garry;34191372]What are you gonna use?[/QUOTE] [url]http://en.wikipedia.org/wiki/List_of_programming_languages[/url]
[QUOTE=garry;34191372]What are you gonna use?[/QUOTE] How about ASP.Net?
PHP is just fine for a large website. It's what people have been doing for years without any problems. MySQL can be a bottleneck if you want to scale it horizontally but even those problems can be dealt with. That being said, if I had to develop a website or server with a lot of requests going on at the same time, I'd probably use Node.js with Mongo.
ASP.NET is a dream if you need a fast web app and you can't afford a fast server. [editline]14th January 2012[/editline] [QUOTE=Xeon06;34191909] I'd probably use Node.js with Mongo.[/QUOTE] sorry, you almost sounded credible until that
Sorry, you need to Log In to post a reply to this thread.