Latest Uploads
Shields 64x64

Pakz

Ffs_Spam

Jayenkai

Hives Screen shot

rychan

Rpg Potion Sprites

Pakz

Super Shap ... ration Kit

Andy_A

Platdude Spotting

Jayenkai

Older Posts
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...

View Topic : Happy Birthday Jayenkai
Happy Birthday Jay!

View Topic : Happy New Year!
A very Happy New Year to you all!

View Topic : Merry Xmas - 2015
A very Merry Christmas to you all!

View Topic : X 240
A bit-shift by a single bit will multiply or divide the value by 2 depending on direction, so a bit-shift will only directly allow multiplication by powers of 2. However, you could achieve multiplication by other amounts by summing the result of multiple different bit-shifts on the original value.

240 is 11110000 in binary, so:
x * 240
= x * (128 + 64 + 32 + 16)
= 128x + 64x + 32x + 16x
= (x << 7) + (x << 6) + (x << 5) + (x << 4)

Although at that point, it would presumably be easier and faster to just multiply normally! What's your intended use case here?

(There are some variants, such as observing that 16 is the highest power of 2 to directly divide 240, and then calculating (x << 4) * 15 [or (x * 15) << 4]. But ultimately the utility of this will depend on what you are hoping to achieve.)

View Topic : Happy Birthday, Shroom_Monk
Thanks, all! Tis intriguing that SoCoder thinks that, though, because I'm actually 22!

View Topic : Happy Birthday, Blanko1324 and Steve Ancell
Happy Birthday Blanko and Steve!

Older Posts -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 738|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Latest Posts
Pokitto
Jayenkai Sun 02:00
Arduboy Owners Club
spinal Sun 01:35
Slow News
Jayenkai Sat 23:36
AGameAWeek : 2017 - Part One
Jayenkai Sat 08:31
Facebook Group
rskgames Fri 10:47
Possible LCD experimentation imminent.
steve_ancell Fri 10:30
1-2-...Never Mind
rockford Fri 07:12
Buy Zelda
rockford Wed 16:00
What Have You Done? - April 2017
rychan Wed 06:43
I Hear Voices
Jayenkai Tue 04:30
More

Latest Items
Showcase : Read Error A
Jayenkai Sat 08:28
Showcase : Hives
rockford Wed 12:53
Showcase : Quadoban
rskgames Fri 10:11
Blog : My Arduino experience.
steve_ancell Wed 17:02
Showcase : Roguelike Explorer
Pakz Fri 06:59
Showcase : Infinitron
Jayenkai Mon 07:50
News : Newsletter #311
Jayenkai Thu 17:27
Link : Super Shapes Exploration Kit
Andy_A Thu 11:09
Dev-Diary : Sensitive - Arduboy!
rychan Thu 17:27
Snippet : Skylines
steve_ancell Tue 14:25
Dev-Diary : PS2 to N64 Adapter
spinal Sun 10:49
Link : Vector Tutorials/Help page.
Pakz Thu 23:00
Blog : mini project
spinal Sun 10:13
Snippet : Wall Tracing on Random Maps (rpg)
rskgames Wed 22:48
More

Who's Online
rychan
Sun, at 16:55
Jayenkai
Sun, at 16:44
Pakz
Sun, at 15:52
HoboBen
Sun, at 13:30
rockford
Sun, at 13:27
spinal
Sun, at 13:02
9572AD
Sun, at 11:47
rskgames
Sun, at 10:04
zzoom
Sun, at 09:45
steve_ancell
Sun, at 05:52
Site : Jayenkai 2006-Infinity | MudChat's origins, BBCode's former life, Image Scaler.