h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

i just wish there was one big include file for all the standard gui stuff that made it like JS
u know how when u make a js file u never have to initialize anything but then again that slows it down
i just wanna b able to go:

include ;
main(){
COLOR color = RGB(0,0,0);
for(int y = 0; y < 255; x++){
for(int x = 0; x < 255; x++){
byte r = (((x - 128) * (x - 128) + (y - 128) * (y - 128)) % 256 + 256) % 256;
byte g = x;
byte b = y;
color = RGB(r,g,b);
setPxl(x,y,color);
}
}
}

or something like that and get it to make a cool gradient graph
>8^B

You know, we campaigned long and hard to get the < space > smiley, just so we could indent code properly in threads....

actually, what i really want is faster compiled js w/ pxl-level control.
like java, only easier to just sit down and write
>8^B

i didn't know that there was a < space > smiley

include ;
main(){
COLOR color = RGB(0,0,0);
for(int y = 0; y < 255; x++){
for(int x = 0; x < 255; x++){
byte r = (((x - 128) * (x - 128) + (y - 128) * (y - 128)) % 256 + 256) % 256;
byte g = x;
byte b = y;
color = RGB(r,g,b);
setPxl(x,y,color);
}
}
}

is this better?
>8^B

actually it would be more like

include ;
main(){
COLOR color = RGB(0,0,0);
byte r = 0;
byte g = 0;
byte b = 0;
for(int y = 0; y < 255; x++){
for(int x = 0; x < 255; x++){
r = (((x - 128) * (x - 128) + (y - 128) * (y - 128)) % 256 + 256) % 256;
g = x;
b = y;
color = RGB(r,g,b);
setPxl(x,y,color);
}
}
}
>8^B

actually it would be more like

include ;
main(){
COLOR color = RGB(0,0,0);
byte r = 0;
byte g = 0;
byte b = 0;
for(int y = 0; y < 255; x++){
for(int x = 0; x < 255; x++){
r = (((x - 128) * (x - 128) + (y - 128) * (y - 128)) % 256 + 256) % 256;
g = x;
b = y;
color = RGB(r,g,b);
setPxl(x,y,color);
}
}
}
>8^B

i'll get it right eventually
i just have had alot of trouble with js trying to make an adequate particle system with long trails because that takes a lot of cycles to update and i realized that if i could keep a simple hypermatrix i could get it to go faster but i still have to use divs with bullets for simple disk-shaped "pixels"
of course if all this code were correct stdio.h would have to be completely remade by the people that make header files. maybe it should be called gamegui.h
>8^B

Hmm, then that would be what Clanlib is for... http://www.clanlib.org

Also various other projects around to provide libraries for games development (including 3D game engines), graphics, GUIs... but there are no standards. C++ does not try to do everything, it simply provides the means to do everything, and leaves the rest up to the users.

It's a bit ironic that there was a time when you pretty much could do simple raster graphics on a PC with a small VESA library to set the graphic card to the right mode (onr or two simple calls), and hardly any subsequent overhead. Even writing the setpixel() routine yourself, all you had to do was take care of memeory bank switching if using a >64K mode, and that wasn't terribly hard.

Nowadays, I suppose there is the DirectX route, which may ultimately be quick, but which does have some definite amount of learning and work required to get any results, or (for initial development if speed is not an issue), there's whatever one's compiler provides.

(In Borland C++ builder, I can stick a TImage object on a form, and with a little setting up, I can get access to a TCanvas object which has a Pixels[][] property, giving access to a bitmap to write to.)

Ah, but when you have access to things like DirectX, SDL, GLUT, OpenGL and so forth, you can do a lot more a lot more quickly than by writing the pixel manipulation routines yourself... especially when you take hardware acceleration into account (which is where a lot of complexity comes from, you need to be able to talk to the hardware drivers).

right now i wanna make a 3d raytracer with the vantage point at 0 pxls behind the camera.
it would work something like setpxl(atan(x/z),atan(y/z))
for(x from -pi to pi){
for(y from -pi/2 to pi/2){
//send out ray from (0,0) at angle (x,y) for (theta,phi)
//use calculus to find intersection with polys, store as MyColor
setpxl(x / pi * 255, y / pi * 255, MyColor)
}
}

Certainly, a solid interface and h/w acceleration is certainly quicker *if* you want all the fancy 3d stuff, but for the absolute beginner, there can be advantages in a simple 8/24/32-bit raster array to get to grips with the basic 2D techniques. I'm sure there's something in DirectX that would do the job, (I'm not certain, since my game programming days were mainly pre-DirectX and I stayed away from the in-house engine as much as possible) but it's getting to the usability point from scratch that can be the problem fro a beginner.

When the interface is simple, if something's wrong, it's obvious that you've stuck pixels in the wrong place.
It can (was?) also be really useful not having a multitasking OS or other huge software layer between your code and the screen - being able to try some optimisations and see undoubted unadulterated raw results does have advantages.

ah, programmer nostalgia
"in my day, sonny, we didn't have those fancy 'languages.' we did all of our programming in bytecode! we had to memorize command lookup tables and use punchcards for input! kids these days..."
>8^B

My dad was telling me about the first computer he worked on. You had to manually key the first four (I think) instructions into the computer by setting eight switches and pushing the store button, then you could push the button to boot it up. It would use those four instructions to look up the BIOS routines and off it went. Heh...

Ion, the whole point was that there *was no* BIOS. He had to toggle in the "bootstrap loader", which I suspect was more than four instructions, to tell it to load the actual program he required from punched paper tape/cards etc.

Calculator Nerd, why reinvent the wheel? There's a wonderful raytracing suite (which I believe is open source) over at http://www.povray.org/ - I used it at length back in the days of my 386DLC/40 PC.

POV-Ray's great, but sometimes you just wanna write your own, just to see how it's done. It's a learning process.

I guess that goes for the pixel-setting stuff as well, although if you're not interested at all in the low levels, the modern libraries are fantastic.

Not that you can't still do the low-level stuff if you really want to. You just need to find the right stuff. On Linux, SVGALib probably fulfils that task.

Guess that's the problem with retelling somebody else's story - I got the details wrong. It did load from paper tape.

actually, a friend of mine overheard my isoraytracer idea and told me about povray. the only prob is that i have not been all too successful installing software in linux. i am such a newbie that i can't even follow the simple terminal instructions (i finally figured out how to log in as root in the terminal without logging out of kde)
>8^B

What distribution are you using? Some of them have packages for POV-Ray (if you're lucky).