[QUOTE=q3k;31715577]There's overkill, and then there's just plain showing off.
Unless you are rendering videos, running a bunch of VMs, using this box as a server (even worse, running Windows on it), or keeping your whole OS in a ramdisk, there's NO reason to have that much memory, let alone be using it all at once.[/QUOTE]
It's Jeff Atwood's PC, he wants to be "ready for the future".
[QUOTE=DevBug;31714335][IMG]http://localhostr.com/files/fwOVJAd/Zombie%20Eat%20Out.png[/IMG]
Working on an editor.[/QUOTE]
Judging by the name, it involves female zombies then?
Also, @Overv, facepunch needs a "He's a silly tit, then", rating :D. There's no point being "ready for the future" in this game: it's a lot cheaper to wait for it!
Now with more shades of grey, giving funky results:
[img]http://dl.dropbox.com/u/2670708/Programming/C%2B%2B/OpenGL%20Landscape%20Noise/OpenGL%20Landscape%20Noise/Fractals.png[/img]
I've laid the groundwork for the Linux chapter and I'll finish it tomorrow. The OS buttons on the site actually work now and you can look at the WIP content if you really want to.
[QUOTE=Overv;31716507]It's Jeff Atwood's PC, he wants to be "ready for the future".[/QUOTE]
does anybody actually like atwood
[QUOTE=Overv;31717344]I've laid the groundwork for the Linux chapter and I'll finish it tomorrow. The OS buttons on the site actually work now and you can look at the WIP content if you really want to.[/QUOTE]
Looks good, worked fine on Ubuntu 10.10
[QUOTE=Overv;31716507]It's Jeff Atwood's PC, he wants to be "ready for the future".[/QUOTE]
Actually, my current PC has 4GB and I remember wondering if I'd ever use it when I ordered it.
[IMG]http://localhostr.com/files/ucTGwwE/capture.png[/IMG]
Thanks to bean and layla. Found out that one function call messed everything up.
I found that the depth buffer is much faster than any sorting algorithm. I have it rendering at four times the speed, but it can still only handle 64^3 voxels at 100fps. And that's with the inside cubes not being rendered.
[media]http://www.youtube.com/watch?v=2n9F3xte6gI[/media]
I'm guessing the next step is to learn how to draw the points with glsl?
I've been running into issues 'porting' my build system from python to F# with IronPython. 9/10 times the issue doesn't lie with the F# side of things, but rather that IronPython tries to automatically map types that implement certain interfaces from the .NET side. It's becoming pretty clear to me that IronPython and F# are not the best of bros (C# implements IronPython functions just fine).
Luckily, I'm not going to let IronPython get me down, so I'm doing 'destructive' changes to my syntax, in that I'm removing a lot of fluff.
The original idea is that a typical build file would look like:
[code]
with staticlib('example') as example:
example.files << 'source/*.c', 'source/*.cpp'
if bit.windows: example.files -= 'source/posix.c'
example.debug.library = 'lua5.1', 'opengl', 'etc'
[/code]
However, because IronPython is a big old dummy, I'm doing this:
[code]
with cxx.staticlib('example') as example:
example.files = 'source/*.c'
with cxx.debug as debug:
debug.library = 'lua5.1', 'opengl', 'etc'
[/code]
There's a whole lot of black magic and inherit DynamicObject() involved with this, but it's a lot cleaner than the Python version, minus the fact that I wouldn't really be removing files from the list ever, only adding them, so I removed that ability. The 'get' within the with statement there is a bit of a misnomer, and I'm looking into whether I can actually pull off creating a target with that name dynamically, or a copy of an object, etc.
On the bright side, with the small changes in the API, this moves the 'project layout' closer to a serialize-able version of the entire system. Such that, I could potentially serialize all the important data, and not actually run the IronPython script unless it has changed. It would also make it easier for when I throw some Continuous Integration "all up in this bitch", but that's for the release after this one. (At least mono makes creating a system daemon easy)
I will say though that the .NET API is pretty good, and that, unlike when writing C#, it's actually fairly quick and easy to write F# in a non-visual studio environment.
EDIT: I actually just did a test, and it worked. I can do `with cxx.whatever as x`, and it creates whatever I want it to. :v:
[QUOTE=Naelstrom;31719291]I found that the depth buffer is much faster than any sorting algorithm. I have it rendering at four times the speed, but it can still only handle 64^3 voxels at 100fps. And that's with the inside cubes not being rendered.
[media]http://www.youtube.com/watch?v=2n9F3xte6gI[/media]
I'm guessing the next step is to learn how to draw the points with glsl?[/QUOTE]
What is that? A cube of cubes? Or is it just lots of cubes on the same position?
[QUOTE=Robbis_1;31722908]What is that? A cube of cubes? Or is it just lots of cubes on the same position?[/QUOTE]
Cube of voxels, each represented by a small cube I think.
After changing up some repos and bringing my Linux server up to full testing i updated a massive number of core libraries, though for some reason a core post install script had some issues, so I went in a changed up some library in Perl, and so far it is working.
And that is the strangest thing i have worked on this weekend, and it is programming related, some scripts did need to be changed.
[QUOTE=Darwin226;31723019]Cube of voxels, each represented by a small cube I think.[/QUOTE]
But they must be overlapping each other to produce that flickering and rendering artifacts that you can see in the video.
[QUOTE=Robbis_1;31723137]But they must be overlapping each other to produce that flickering and rendering artifacts that you can see in the video.[/QUOTE]
Looks like stripes to me.
[QUOTE=Robbis_1;31723137]But they must be overlapping each other to produce that flickering and rendering artifacts that you can see in the video.[/QUOTE]
I don't see any flickering really.
I've managed to implement return values, and now, instead of translating it into assembly, and then copy-pasting into an inline assembly statement, I compile directly to x86 instructions!
[cpp]
int x;
int y;
int t(int c)
{
int b()
{
return c + 5;
}
return b() + 10;
}
t(25);
[/cpp]
Turns into 172 bytes of instructions, and returns 40, by the way.
Disregard the x and y, they were only there to debug some stack variable lookup stuff.
[url]http://open.gl/?page=context&os=linux[/url]
This is funny.
[quote=open.gl]I never managed to get OSX to run on any virtual machine, so someone else needs to do this.[/quote]
You can run OS X Snow Leopard on VirtualBox
[QUOTE=CarlBooth;31724226]You can run OS X Snow Leopard on VirtualBox[/QUOTE]
I tried, I gave up.
[quote="open.gl"]explain that groundwork is shit and you want to draw something[/quote]
This is actually sort of amusing apart from being useful
I found it quite easy to run on VMWare Workstation.
Yeah, it runs natively on VirtualBox
Only a [url=http://pastebin.com/C3YUD8b9]slight config change[/url] is needed in the machine XML file, no changes to OS X required.
I even used a Retail DVD from my Macbook.
[QUOTE=CarlBooth;31724513]Yeah, it runs natively on VirtualBox
Only a [url=http://pastebin.com/C3YUD8b9]slight config change[/url] is needed in the machine XML file, no changes to OS X required.
I even used a Retail DVD from my Macbook.[/QUOTE]
dont you need to use a special boot loader or something?
No VirtualBox has full support for EFI
[QUOTE=CarlBooth;31724535]No VirtualBox has full support for EFI[/QUOTE]
There are tons of EFI Loaders for OSX
[url=http://netkas.org/?p=372]PCEFI[/url] and [url=http://www.mediafire.com/?thd5nmo2oyn]Empire EFI[/url] to name a few.
Why is this so difficult to believe?!
[u]You don't need any 3rd party loaders, kernels or other software, just a standard Snow Leopard retail disc.[/u]
[quote][IMG]http://i.imgur.com/OjEa8.jpg[/IMG][/quote]
- Turn on VT on your motherboard
- Make a new Virtual Machine, machine type OS X Server
- 2GB Memory
Exit VirtualBox, open the machine file in notepad, paste that line I posted in to the ExtraData section.
- Re-open VirtualBox
- Set the Graphics Memory to 128MB
- Put Snow Leopard disc in to DVD drive
- Install Snow Leopard
All updates work, as you can see. I installed 10.6 and it updated straight to 10.6.8 no problems.
[QUOTE=CarlBooth;31724613]Why is this so difficult to believe?!
[u]You don't need any 3rd party loaders, kernels or other software, just a standard Snow Leopard retail disc.[/u]
- Turn on VT on your motherboard
- Make a new Virtual Machine, machine type OS X Server
- 2GB Memory
Exit VirtualBox, open the machine file in notepad, paste that line I posted in to the ExtraData section.
- Re-open VirtualBox
- Set the Graphics Memory to 128MB
- Put Snow Leopard disc in to DVD drive
- Install Snow Leopard
All updates work, as you can see. I installed 10.6 and it updated straight to 10.6.8 no problems.[/QUOTE]
You said virtualbox doesn't have full EFI support. I'm sorry, you have confused me.
[QUOTE=wingless;31724734]You said virtualbox doesn't have full EFI support. I'm sorry, you have confused me.[/QUOTE]
[QUOTE=CarlBooth;31724535]VirtualBox has full support for EFI[/QUOTE]
No he didn't?
[QUOTE=esalaka;31724747]No he didn't?[/QUOTE]
"No VirtualBox has full support for EFI"
Should be:
"No, VirtualBox has full support for EFI"
This is why grammar is important.
Sorry, you need to Log In to post a reply to this thread.