Latest Uploads
Invasion V ... prototype

rychan

Invasion V ... Prototype

rychan

Shields 64x64

Pakz

Ffs_Spam

Jayenkai

Hives Screen shot

rychan

Rpg Potion Sprites

Pakz

Older Posts
View Topic : Router Rebooter
The original V1 Virgin Superhubs (such as what's in the house I currently live in) have a known issue where they don't have enough memory (or there's a memory leak, or something of that ilk), which causes them to gradually slow down over time. Until you reboot it and the memory is cleared out. Apparently it gets worse as the hardware gets older, too.

Don't know if that's the hub you have or not, of course, but figured I'd mention it just in case.

View Topic : Design a Theme!!
Ah, the old ShroomCoder theme. The joys of looking back at things you made in your childhood and thinking 'ow, my eyes, what on earth was I thinking when I designed this?'

Does anyone actually use it?

View Topic : Any Feature Requests?
One way to avoid spam (to some degree, at least) would be to bundle up lots of posts happening around the same time into a single email. So rather than sending an email as soon as a post is made, you could every (for example) 15 minutes check if any new posts have been made, and if there are any, send an email listing them. You could also make the time period customisable per user, though that does make things a little more complex.

View Topic : CSS-Me-Do - SoCoder2
Could you have your PHP generate the content of the different sections in whatever order is convenient to you, store the results in strings, and then just output them at the end, rather than outputting as you go?

View Topic : CSS-Me-Do - SoCoder2
Hmm, I've had a fiddle with it, and can't seem to make anything work. Yay CSS!

I did notice, however, that the crux of the problem is that the Main Content block's width is 100% of the page width (|edit| which isn't obvious unless you use the browser's 'Inspect' feature, since the sidebars cover it |edit|), and so the table is basing its 100% width on that. But the Main Content text still seems to position correctly with respect to the floated divs, and I'm not sure why that is.

View Topic : CSS-Me-Do - SoCoder2
I think use of 'float' will solve this, so long as you move the Main Content block to be at the end rather than the beginning. (although you had a preference for putting main first, putting it last is still better than in the middle, right? )

-->

Disclaimer: it's been a very long time since I've done any web-dev, and this was just the result of some quick fiddling, but I'm fairly certain this works. Though I've only tested it in Chrome...

I think the reason it works is because it will first position each of the 'floated' sidebars, and then try to fit the Main Content block in, which wants to be as wide as it can because of 'display: block'. With the sidebars already in place, Main Content can then squeeze into the middle. But if you put Main Content first, then it takes up all the space it can takes up first, and then the sidebars try to fit in where there is space. Similarly, if you put Main Content in the middle of the code, then the left bar will float properly, then Main Content will try to take lots of space, and then the right bar might end up forced to be in the wrong place. So I think the ordering does matter.

View Topic : Spinal's Code

View Topic : Spinal's Code
It almost certainly shouldn't, so there's probably something else going on. Do you have some example code?

View Topic : replace two half bytes with one byte?
Here's a simple C++ example that I think does what you want. |edit| (although on subsequent readings, I'm not quite sure what you're getting at with the second sentence; I think what I've done covers the first) |edit| It can be made more concise than this, of course, but I've spread it out to make it easier to follow.

-->

View Topic : RIP : Jay's Dad
My condolences, Jay. It sounds like his distance from the rest of the family makes it complicated to work out how you 'should' feel, but I don't think anyone here would see it as 'heartless' - as rockford says, it doesn't sound like the apathy is unwarranted.

All the best.

View Topic : Happy Birthday, Jayenkai
Happy Birthday, Jay!

*remembers when he was the youngster of the forum*

View Topic : Happy New Year! (2016-17)
Happy New Year, one and all!

View Topic : Merry Xmas - 2016
Merry Christmas to you all!

View Topic : Spinal's Nunchuck GameBoy
I mean, that will technically make it work. Though I'd still be inclined to caution that including those CPP files will come back to bite you again later!

(renaming them to .hpp would have solved it without the static)

View Topic : Spinal's Nunchuck GameBoy
As a general rule, if you're including files in C / C++, you should only include header (.h, .hpp) files. When you compile your program, the compiler will compile every .c / .cpp file separately, then link them all together to create the final executable. So if one your files includes another .cpp file, you have defined the contents of that .cpp file twice - once in the original version, and once in the file you included it into.

|edit| To clarify slightly, the cause of your 'not in scope' error is that Wii is in scope in the code snippet you have posted, so that compiles just fine. However, when the compiler then compiles joystick.cpp, Wii hasn't been defined in that file! Hence the error. |edit|

View Topic : HoloDeck?
I really don't know how to convey the concept to you in a way that you can accept.


Right back atcha.

What I'm saying is that only the screen res times two 64-bit Ints (16 bytes) are needed be streamed per atom in view (on the screen).


What are these two integers storing, exactly? You cannot project a 3D location in space onto a screen without the position data.

The rest of the required information is stored in RAM. Each atom has access to color (4 bytes), normals(12 bytes), position (12 bytes) from data already in memory (envision massively indexed look-up tables). You don't need peta-bytes to store that kind of information in RAM.


You are assuming that we're only going to preload into RAM precisely the 1024*768 pixels we need for a frame. But in reality, of course you're going to need more! There's no way you could compute which atoms you'll need, and move them from disk to memory, before you've computed which atoms you need! At which point yes, as per my calculation above, you do need far more memory space than is feasible. It's just simple maths.

What's more, much of that information will be redundant, one shiny spot will have similar if not the same values no matter where it is on screen.


That isn't at all how lighting works, but ok.

View Topic : HoloDeck?
"Andy_A" What if the 'atoms' contain most of the pixel information needed in the data base/structure, surely you wouldn't want to re-load or re-calc that information. Maybe you could try to envision the majority of the needed rendering information as a matter of using the right pointers to the different parts of the data. The 'position' is the pixel position on screen, not necessarily calc'd at runtime to render the scene, only an elevation and atom index is needed at any given screen position.


Oh, you would certainly want to store it all in RAM, yes. But the reason we were doing streaming calculations from the hard-drive rather than assuming it's all loaded into RAM was because we made the assumption that you only need to load the atoms you are drawing this frame (thanks to this magical search algorithm), rather than any other atoms we don't need yet. If you loaded all the atoms into memory (or even a fraction of them), you would quickly run out of space, making RAM infeasible.

As a demonstration: in the video they claim to have '64 atoms per cubic millimetre'. So, by our previous estimate of 27 bytes per atom, that's 27*64*10^9 = 1,728,000,000,000 bytes per cubic metre. 1.7TB of RAM to store one cubic metre of geometry! Say you only loaded a tiny amount of the data, such as a single cubic metre into 4GB of RAM - that give you about 0.15 atoms per cubic millimetre, or 150 per cubic centimetre. Now, that's not terrible on its own, even if it is less than a quarter of a percent of what they claim, but that's only for a single cubic metre of stuff. To make the kilometre wide island they show you'd have to be repeating the same cubic metre all over the place, or just have a handful of cubic metres of geometry to tile around - which is, indeed, exactly what you can see in the video.

My point is, no matter what your search algorithm is, at some point you have to load this data from somewhere. You either have your search algorithm detect its precise location on a (fairly massive, as we can see) hard drive, a which point our previous calculations on streaming rate become the bottleneck, or you preload it into RAM, except no feasible amount of RAM could hold that much data. Fundamentally, without some clever trickery - for instance, reusing the same tiny bit of geometry over and over, as can be seen in their demonstrations, which clearly isn't actually useful to making a game - what they are claiming is demonstrably impossible.

"steve_ancell" I think I remember something about a binary tree system, maybe that's how they got around the speed issue.


It's almost certainly something like that, yeah - though possibly an octree (eight children per node) rather than a binary tree (two children per node), since 3D space. Any search algorithm for 3D space can only be efficient with some kind of spatial partitioning of the data. Admittedly my experience with that kind of data structure is fairly limited, but I don't see quite how one can make it efficient with ray-tracing (which they must be using some variant of, given their claim that they only need to load precisely one atom per on-screen pixel).

View Topic : HoloDeck?
He's basing most of his assumptions from existing 3D polygon based rendering


No, they're based off the minimum data you need for lit 3D rendering in any kind of 3D system (e.g. ray-tracing). You need the position and the colour to draw anything, and you need normals for shading. The calculations above are the data transfer needed for the 'just a look up'.

|edit| And that's per frame of rendering, not animation. The animation considerations are a whole separate issue. |edit|

View Topic : HoloDeck?
Surely that's just 18,874,368 pixels to process per second, not bytes? Assuming such a search algorithm only requires the world coordinates to locate a point in the cloud, and that those coordinates are XYZ coordinates stored as 3 single-precision (i.e. 4 byte) floats, that's 12 bytes per point, so 226,492,416 bytes per second.

And that's ignoring the fact you also need to stream the colour of the pixel you've located from disk as well, which at 3 bytes for RGB (assuming no alpha term for transparency) brings us up to a total of 15 bytes per point, or 283,115,520 bytes per second.

The video includes an example of lighting on a model, which will require per point normals too, so you have to throw in an extra 12 bytes per point for those, taking us to 509,607,936 bytes per second.

And allll that assumes that this is a static scene, entirely on a hard drive (capable of shifting half a gig per second), with no animation or moving parts, because those need to be calculated a run time, so can't just be streamed straight from disk.

I could go on, but I won't, because as pointed out this topic is really meant to be about this 'holodeck' rather than retreading the same ground on the 'infinite detail' stuff. As far as I can see, though, they don't give any explanation of how these are supposed to work (regardless of whether they are powered by point-cloud or polygons) - in the video, it looks like stuff projected onto various walls that follows the perspective of the camera filming the person, rather than the person themselves. And from an optics perspective, there doesn't seem to be any explanation of how 'ordinary glasses' are supposed to achieve a 'hologram' effect. I assume they're using polarising glasses, as in 3D cinema, and the screens would track the movement of the user? That doesn't seem impossible, I suppose, but I have a hard time believing that gives a better head tracking experience than a VR headset would.

(Though of course, since I lack the means to try either, I have no way of actually verifying that... :/ Don't suppose we have anyone in Australia who is actually close by? )

View Topic : HoloDeck?
An interview conducted by someone who works in 'community relations' at the same company? Seems legit.

View Topic : HoloDeck?
Oh, these guys again. I'm genuinely surprised they still have the money to keep going with this...

It's still almost certainly complete rubbish, though. The video seems to be trying to use this new holodeck stuff to try and legitimise the old point-cloud rubbish, but once again they give only the same 'it's infinite, it's not polygons' 'explanation' rather than any actual technical detail about how this works. And if, after ten years, they still can't give any technical detail (especially given their claim it all runs in software rather than on a GPU) as to how this supposedly works, then it is, almost certainly, still a fraud.

View Topic : Jay Plays with Mandelbrot
Many years ago, I wrote various fractal generators in BBC Basic, including Mandelbrot. Unfortunately, it seems my copies of that old code have gotten corrupted somehow, or I'd share those versions... :/

View Topic : Happy Birthday Shroom_Monk
Thanks guys!

View Topic : TEN : Happy Birthday, SoCoder!
Lots has happened in 10 years... Happy Birthday, Socoder!

View Topic : Keeping in Contact
*emerges from lurkerville*

Still alive over here, just very very busy trying to get my final university project finished for the deadline next week. But once that's done, I'm done forever! And maybe will then have some time for my own coding projects...

Older Posts -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 575|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Latest Posts
Cerberus X - the continuation of Monkey X
zzoom Fri 23:13
Crystal Maze
zzoom Fri 23:02
Update All Objects in Array?
Caton Fri 20:09
CSS-Me-Do - SoCoder2
rskgames Fri 09:45
Delete Button on Showcases
Pakz Fri 09:13
Grenfell Fridge
Jayenkai Fri 09:02
ProcGen Book
Pakz Fri 07:11
XB360 /XBOne Pads
STEVIE G Thu 23:28
Winter Solstice
therevillsgames Wed 16:47
AGameAWeek : 2017 - Part One
Jayenkai Wed 15:10
More

Latest Items
Link : Learn C++
rychan Fri 03:13
Dev-Diary : My Journey into NES Development
Jayenkai Thu 03:58
Showcase : A Civilization Clone v0.4
rychan Thu 03:27
News : Newsletter #320
Jayenkai Tue 18:47
Blog : sadas
hardcoal22 Tue 02:50
Showcase : Flappadiddle
Jayenkai Mon 08:20
Article : Cookie Information
rychan Sun 12:28
Dev-Diary : Wii to N64 adapter
spinal Sat 11:50
Link : MonkeyX code examples
Jayenkai Sat 06:42
Link : Available Languages
Jayenkai Thu 13:22
Blog : Mr Testo Tests
Socoder Tue 07:21
Link : Chrome VR Experiments
Jayenkai Tue 06:49
Showcase : Orbital Projectiles
Jayenkai Tue 06:39
Showcase : Hives
zzoom Fri 16:10
More

Who's Online
zzoom
Fri, at 23:13
Caton
Fri, at 23:07
Pakz
Fri, at 22:59
9572AD
Fri, at 22:45
rskgames
Fri, at 21:57
therevillsgames
Fri, at 19:11
GfK
Fri, at 18:37
Jayenkai
Fri, at 16:31
steve_ancell
Fri, at 16:31
rychan
Fri, at 15:42
Site : Jayenkai 2006-Infinity | MudChat's origins, BBCode's former life, Image Scaler.