Holy...

I'm definitely going to have to take a look at your source, though I doubt I'll be able to make many improvements to it lol

Oh, that reminds me... I really should comment this. Of all my projects, this one is probably one of the most important to comment, because it's really math-heavy and employs some algorithms that sometimes confuse even myself and should definitely be explained. I'll get around to that later today.

this is sweet. can we have an executable?

I just attached a zip file to the first post containing all the source and executable files.

Can it do variable height raycasting? +1 anyway for the optimizations that I know are coming.

Not yet, but I guess it's certainly possible. I'll look into adding features once I can make it faster though, because it already struggles to run smoothly at 15MHz even at 64x64 with no textures.

I also need to try to improve collision detection. If you walk into the outside corner of a solid block at certain angles, you don't collide with it and just walk right into it.

A main reason why not much more than 4-level grayscale has been done before is because the screen driver is so slow. Even if a program theoretically uses a high level of grayscale, the screen and driver are physically incapable of producing much more than a somewhat solid-looking 8-level grayscale.

I think I might have been the first to notice it and upload a file of that type. Not sure though.

I attatched my solution (602 bytes) to my original post saying that I had completed it.

The tricky part of this is trying to compress it in a way that the size of the code itself doesn't offset the amount of data saved, because not much data is being compressed.

But I got 608 bytes. Storing the data as a raw picture and putting it onto the screen and buffer would take 777 bytes. If anyone gets any better, let me (and Builderboy) know.

EDIT: 606 bytes.

EDIT 2: 605 bytes.

EDIT 3: 602 bytes. I think this is as small as I'm going to get it, so I'm attaching what I have. I included two versions because, although the second is 2 bytes larger than the first, you might consider it better. Whereas the second one updates the screen all at once, the first one updates the screen 4 times throughout the process due to the Bitmap() calls drawing directly to the screen. This slight delay isn't very noticable, but I figure I'll just give you both options.

EDIT: I should ask: what drawing routines will already exist in the program? I don't want to use the rectangle routine, for instance, if it doesn't already exist and adding it would inflate the code larger than using some other method.

Simple bug: the *-1 auto-optimization is missing.

BTW: I have to thank Runer for the Avatar.

I remember making that!