Messages

Skynet

Maybe I can do some of that this weekend. This week's work and a strong wave of heat and humidity here are a killing team.

FreeBasic actually uses GCC as a back-end so algorithm speed should be similar. Now I can't talk about the efficiency of the internal graphics library, but it's the only simple one I've found that I feel comfortable with. I've been interested in finding a good way of using it in C. Since the library was written in C originally, it has to be possible, but I have to do some research. The other idea would be to just read the source and see how the individual OS calls are handled for graphics and make my own, even simpler graphics library.

Not sure what you mean by transparent triangles, but I do handle 1-sided and 2-sided triangles. 1-sided triangles are only drawn when the orientation is positive and are eliminated from sorting at an earlier phase. My engine also decomposes polygons from Stunts to triangles. It does it in a rudimentary way, but because Stunts doesn't seem to use concave polygons in its models, it works well.

About licensing, my thinking goes like this: Stunts is like "freeware without papers". I'm OK with people redistributing it, it's on my site (Race For Kicks), but I'd immediately take it down if I were told to by any authority. I openly ask for anybody owning it to engage in communication with us and I'm willing to do anything legally required to be allowed to distribute it the right way. Only reason that hasn't been done is because we haven't been able to get in touch with anybody official. And if they don't want to allow it, I'd take it down. With my software (which is always free software), I wouldn't distribute it, because it'd violate my own license. On the other hand, creating free software that works with Stunts is perfectly legal. Say, I can make an engine that reads the original files and I can distribute the engine without the original files. Finally, if the moment comes when we want to have free models, it's not hard to make new models that will resemble those of Stunts enough to serve the same function and they would be legal.

For the 3D, I think it'd be simpler for me to make it the second way, that is, to extract the individual elements and turn them into text files and then give another text file with the offsets and rotations for those elements.

Oh, about the engine in DOS. I haven't tried to compile it there, but surely the problem is about the screen resolution. You need to change that near the top of the code to a resolution DOSBox supports. My engine uses 32bit true colour, so The maximum resolution you can use in DOSBox is 800x600. Otherwise, you'd have to look for the place where the screen resolution is set (it says ScreenRes) and set the third parameter to 16, which will bring the colours down to 16 bit high colour. Then you can apply a resolution of up to 1024x768. Resolutions in DOS have to be exact.

Uhm... well, if one of these can do the trick, it could get its commented default configuration for Pretty Garage

Heart (band)

Ha, ha, ha... Yeah, these are the tasks I like doing, so I would like to. Only I feel soooo lazy!  But at least I can try to get you the 3sh-to-text thing if I have some time.

There is a slightly newer version of the engine. I've been very untidy with it and it's always attached to something else. The version I posted in Race For Kicks contains a track viewer. The other version is more interesting, but harder to use, but I wanted to post it after some touches to make it more friendly. It can actually replay "multi-player" races and sort of allows you to make a video out of them. It can draw cars... cars without wheels, ha, ha, but cars.

For just printing all the coordinates and colours of or triangles in a frame, I suppose I can just hack on the triangle drawing function and have it write to a log. Or do you mean all 3D triangles, that is, prior to rendering?  That's somewhat more complicated, though possible.

I think if we discuss these things enough, we might be able to find a way to do some team work here. We work very differently, but in the end, we are heading more or less in the same direction.

Sorry, guys, I'm making it too long!

But I forgot to answer this technical thing Matei mentioned. One of the glitches you can see in my engine there is that large objects placed on top of hills or water sometimes experience Z-fighting, as pointed out by Matei.

You were saying, Matei, that I could just draw all terrain first. I have already thought of that, but it isn't that simple. I'll explain the technical details. You'll see that general the 1x1 track elements don't have this Z-fighting problem. This is because I calculate the distances by averaging the four corners of the base of track elements and then I lift that up a little bit to make it closer to somebody looking from the top. That is enough for elements that size. The problem is that bigger elements that are, say, 2x2, have their centre further away and so the centre of the 1x1 hilltop or water "wins the fight". If I force all terrain to be drawn first regardless of distance, I will be able to see objects through hills, so I need to find an intermediate solution.

I can think of many possibilities. One is to create a new object that's 2x2 but actually made of 1x1 hilltop sub elements and place it whenever there's a large object on top. It would work, but I don't like it much because it makes my engine even more dependent on Stunts' grid. Currently, my engine is a little more free than Stunts. For example, you can place objects that are not aligned with the grid and rotate them at any angle around the vertical, not just multiples of 90 degrees. I don't want to lose this freedom.

Stunts clearly solves this by placing everything on a grid. My engine only uses the "grid" when loading the track. After that, all is free. I wanted it to eventually allow for adding more features.

I could also be more "subjective" and add a distance threshold and then, when sorting objects, terrain objects always lose if the distance difference lies within that threshold. It can fail, but it would improve the things.

The real solution to everything is Z-buffering, I know.

Uhm... so say you are at C:\this\directory and there's a zip file there called thisfile.zip and you want it to be unzipped and it's contents dropped at D:\this\other\directory. Do you necessarily have to go there, that is, do something like this?:

Code Select Expand

d:
cd \this\other\directory
expand c:\this\directory\thisfile.zip
Can you also do something like this?

Code Select Expand

expand .\thisfile.zip d:\this\other\directory

Well, the good thing about files similar to these is that you can read what you want and ignore the rest. We just need to agree on default values.

Yikes!!

Quattro

What Daniel3D mentions about Stunts is very true and reminds me of something I frequently say about DOS when I compare it to modern OSs. I like saying that "the greatness of DOS wasn't in what it would give you, but in how much it wouldn't stop you from doing". Stunts today isn't just the game that came in the box, it's the game, plus what we've created on top of it and I don't just mean software, but the things we like doing with it... like live races, for instance. So... it's the same software, but we've made it a better game.

My little engine is based on a Painter's Algorithm. I did that because that's what Stunts does. This sort of algorithms can be very fast once optimised and if you make your models for it, they can work well. Yet, no Painter's Algorithm is perfect. It is always possible to make them fail. They are a simplification of rendering, a trick. Z-buffer is the "right" way to render 3D graphics. It is much slower, but if very optimise, it can work even in software and in high resolution on modern machines. Now, models made for a Painter's Algorithm won't look good on a Z-buffer in general. You have to recreate them. Z-bias strategies have to be implemented otherwise.

I would love to write a Z-buffer engine for this, but I do think it's worth to also complete my work on this PA-based engine because it's so easy to make it run fast. My code is currently very far from optimal. As you pointed out, I've been using the Line function instead of a blitting routine and it still runs very fast. The Line function is terrible for this purpose: its coordinates are double precision floats and it's designed to draw diagonal, not horizontal, lines, so it make a lot of unnecessary calculations as it draws. My idea is to eventually replace the whole triangle drawing routine with an assembly based one and allow to fall back to this high level one in case you want to compile the game on something other than x86 processors (don't think it will happen). For Z-buffer, this is absolutely required.

What I need from a graphics and real-time input library is:
- Ability to copy a block of memory onto the screen or graphic window
- Ability to read mouse X and Y and buttons at any time
- Ability to retrieve the current status of the keyboard at any time

Anything else is just bloating it. A library like this should take some 500k or less statically linked. Yet, that has been the holy grail I've been looking for for a very long time.

I've made a little game with sound that runs on GNU/Linux on Windows in FreeBasic before. I didn't exactly include a third party library, although the OS API is itself a library, so in a way, it does call a library I didn't write, but that doesn't count because ALSA is practically guaranteed to be found on every GNU/Linux freshly installed. So I read some code another guy had used and created my own little library based on it. It does do something weird with the sound channels, though, I don't know why, but it sounds perfectly OK.

Yep, CarWorks is a little buggy, especially the 3D part... but not because of the rendering. It's because the arrays that handle the primitives are a mess there. I have to rewrite that part. And yes, it's only for cars. But we have Stressed, that can handle other shapes. It's not hard to produce a text file from 3SH files... It'll be a lot larger and slower to load and parse, but it could give you an idea of the structure. If I get the time, I'll try to do something like that for you. Until then.... https://wiki.stunts.hu/wiki/Resource_file_format#3d_shapes

This is the format spec we've developed.

We have the 3D model format very well documented. You can use Stressed or CarWorks to turn it into OBJ, but then you lose some things that can't be represented there. My engine, the one you saw, has had some additions more recently, but it's essentially the same thing. It reads the actual 3D models from Stunts, but you'll see some glitches. These occur because, while both my engine and Stunts use a Painter's Algorithm, I can't possible guess the exact details they used and then, some things are rendered differently. This can be solved by re-creating some of the models. Also, re-creating them would rid us from licensing problems, so eventually, that could be a solution.

I've been using FreeBasic mostly because of its very small and portable graphics and real-time input library. I would like to work in C, but libraries I found are unnecessarily huge and can't be statically compiled. The way I work, I only need very basic functions from it, because I do mostly everything by hand. I like to make my software so that you can just copy it somewhere and run it without having to install dependencies. I love GNU/Linux, but that particular thing is often one of its weaknesses.

I would like to make a complete graphics+physics engine for Stunts that still looks like Stunts, only native resolution and maybe a few more features (such us more drawing depth, like what I've done) and have it read the original files, so that we still feel we're playing Stunts. And then add modularity to it so that it can grow and be free software. My skills are growing, but there's still a long way to go. So I really admire where you've been able to get to.

Wasn't the white in Stunts palette #fcfcfc while the background in Stressed is #ffffff?

Hello, Matei!

I had come across Skunks at some point. We've been noticing different approaches at games that either resemble Stunts or have a relatively similar objective. I have to agree with Dreadnaut there, you know, this is a Stunts-loving community. Nobody here consider Stunts even "a little boring", ha, ha.

Anyway, Skunks looks really good and it's nice to see it running and giving a feeling similar to that of Stunts in many aspects. We have wanted to extend Stunts in many ways for years and to some degree, we managed to do it. We can make our own cars and also tracks that would not be allowed by the original games, we have some mods. But there are things we always dream of and we don't have. Like, tracks always have two layers and three levels, that's it. And they're always 30x30. We haven't been able to add new track elements without replacing existing ones and borrowing their physical models. Things like that.

Of the things we like the most about Stunts as it is, probably one of them is how unique cars can be and what they can do. In spite of the crazy physics we get sometimes, racing in Stunts is a lot of fun, allows for the development of skills that make a great difference and get you to really feel the vertigo sometimes. I'm sure the other guys can make a long list of their own favourite things about Stunts.

But if you don't like racing Stunts, this can still be your place. Feel free to join us. See... I do like racing, but I'm a pretty awful pipsqueak myself. I usually do more programming and socials here. I also enjoy making roller-coaster-y tracks. My programming style is very different from the usual trend, but like you, I love free software and that's another thing we'd like from Stunts if it were possible. I have worked on a 3D engine that follows the style of Stunts... and I don't just mean its looks, I mean, that's written from scratch, draws by software, etc. It's kind of a pain, but it has its charm. Now I wanted to develop physics, also the same way, from scratch, no 3rd party code. Maybe I ask myself too much and that's why I'm stuck, ha, ha, but then if I get to do it, I'll be very happy.

I like how you want to keep everything free and try to avoid dependencies. I see you're a GNU/Linux guy too!  Very good! 

Dennis Hopper

Yes, that one is better, but it brings me one concern. You currently can set up in the configuration which unzipping command you will use and its arguments. Because I'm only unzipping and nothing else, I can verify success by checking on the present of the resulting files. I don't need to read the output. If I want to query the file list, I will need to check on the output, but different unzipping programs may have a different listing output format. Maybe some can't list the file names alone and provide some table form instead or something. I could be losing support for those if I do that.

I really don't know what's more commonly used in Windows for unzipping from the command line. I think in most GNU/Linux systems, it's InfoZip