|Logo by Nickman |
(anonymous IP: 126.96.36.199,0)
Total files: 4326
Full index file
Recent index file
Support the site
[Show comments] [Show snapshots] [Show videos] [Show content] [Show crashlogs]
Quick Port of the TimeLess project , first of all there is no sound in it yet so don't whine about that missing. ---------------------------------------- Keyboard controls: escape = exit f = fast forward space = pause 1 = flip to showing the offscreen 256x256 bitmap This package is released under the GPL. CHANGE HISTORY + BACKGROUND: --------------------------------------------- Fri Jan 27 08:07:49 PST 2006 David Ashley (dash()xdr.com) Version 1.00 This is a port to linux/SDL of Tran's (aka Thomas Pytel) Timeless demo of 1994. The demo was written in 100% assembly code and so wasn't portable. I spent a lot of time looking at the demo in those days, and showing it to other people (so I must have liked it). It is worth keeping around, I think. It was an MSDOS program with its own dos extender, which lets you use 32 bit instructions + addressing modes. There were various complications in doing the port. The code was designed for VGA mode-x which separates every 4th pixel in the video memory into a separate region of memory. This lets you get access to more than the 64K video memory window alotment and you can do page flipping. However it's a headache to program. And it made the task harder because this code has to be unravelled. Under SDL we're just a flat 320x200 frame buffer. There are 3 layers to the demo. Layer 0 is the background. In the original source this is done using a 32000 word table that tells you how to move in an offscreen 256x256 byte buffer. The movement in the buffer wraps around in both x and y. Onscreen you're seeing a warped display of that buffer, and that's the most interesting visual affect of the demo. I didn't want to have too much data in this source, so I wrote code to generate a buffer similiar to the one in Tran's source. It uses sines and cosines and I tried to come up with a model for Tran's choice of the radius. I think the intent was a 3D projection, however I don't really know what his choice of R values were based on. This probably makes no sense whatsoever but I can't be bothered to explain. Suffice it to say my algorithmically generated warping table is almost exactly like Tran's, however with mine you can see how it's generated in the source. His algorithm must have been quite similiar. The 1st layer is drawn into by all the r_pXX functions. I've implemented these all. The 2nd layer is the sprites that move around the screen. These just add some spice to the demo. These sprites were implemented in the original source as data statements. It turns out the data statements represent X86 machine language code to bang the right byte values to draw the sprites onto the buffer at the address pointed to by edi. I wrote the gensprites.c program to decompile these programs and output pixel data, which becomes the sprites.c file. All the 2nd layer sprite hacks are implemented in this version of the source. These are the r_l1pXX functions. The 3rd layer is on top of the sprite layer, and I haven't implemented any of these functions. This layer shows a circle and the circle is meant to represent a sort of window into something else. In one instance the window is a view into the offscreen 256x256 bitmap -- sort of the magician showing how the trick works. This is a very nice touch by Tran, in my opinion. Another window just shows a representation of the entire screen, shrunk down so it fits into the circle. You can even see the circle itself in the circle as I recall. Meanwhile while these 3 layers are going on, there are palette effects going on, the colors are changing in interesting ways, fading in and out, etc. The layer0 background is also getting shifted around, the scanning point is moving around, the angle offet, and the scanning table itself is getting warped. It all adds up for a lot of variety. My original intent with this port was to make a cross platform version that would pass down through the ages, and be identical to the original version in every way. That means at exactly the same frame you'd see the same sprites moving around, the 256x256 bitmap would contain the same data, the music would sound the same -- in short it would be a faithful reproduction of the original. However over the course it has gotten extremely tedious to study the code and divine what was the original intent. It is very easy to make a mistake. The code is real spaghetti, difficult to read. It may be fast but it's not very intuitive. I have given up on even implementing the sound for now. This is unfortunate, because the music that plays during the demo is a big part of the demo. It's kind of haunting. You can run the original timeless.exe under dosemu. It runs slower than hell, but you can run it. I got some things to appear right. But the background doesn't match at the right place + the right time. My background gives the same "effect" as the original, however it's not frame by frame identical. I discovered there are some timing dependencies on how the palettes are faded from one to another, and my version doesn't match the original. I was trying to study the original to figure out the original code's intent when it just hit me...I don't have time to get it absolutely perfect. I just sort of gave up. My version is close enough to the original to reflect the essence of Tran's intent, in my opinion. If someone wants to make it absolutely identical, well the source is right there and you can figure it out. I can confirm: 1) All the sprite image data is identical to the original 2) All the background 32x32 bitmap data is identical to the original 3) All the palette data is identical 4) The random locations of the fishies appear to be identical. Perhaps other l1 sprite code is identical. I think the snow was identical, I saw similiar patterns between the two. 5) My handling of palettes is not exact, and so the timings are off. This could affect everything. There is some machinery in there to fade the palette at 1 unit per iteration, or 2 units per iteration. It looked like the decision of which speed to use is based on how many colors are to be faded. That's when I gave up, it seemed ridiculous. 6) I think my gnbg routine is correct, but if the scanning of the starting point in the 256x256 offscreen buffer doesn't match that would make the appearance not match. Anyway Tran says it took him 1 to 3 weeks to write the demo. I've probably invested about a week or so in this port. I can't see putting more time in the port than it took to make the original -- just to make the port *exactly* like the original. So I'm calling it quits. If this is useful to anyone that's great. I'd like to see it rolled into an xscreensaver hack, that would be cool.