The Icon Bar: The Playpen: Slightly cold news on page 10! Phlamey breaks the server.
| |
Slightly cold news on page 10! Phlamey breaks the server. |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
richard cheng |
Message #103200, posted by richcheng at 10:39, 29/6/2007, in reply to message #103164 |
Posts: 655
|
...and some screenshots. Woo!
I think processing the textures I've got (i.e. duplicating and modifying them to make the variants required) is going to take a long time. And there's no guarantee that the end result will look any good  I should probably go looking for some more at some point. Or maybe I just need to be a bit more thorough, i.e. get some simple base textures (ordinary tarmac, ordinary brick, ordinary windows) and cut-and-paste the different elements ontop of each other to manually put road markings on a road, windows on a building, etc. Which is perfectly possible, but would still involve me finding some more textures so I can work at a higher resolution.
[Edited by Phlamethrower at 22:32, 23/6/2007] Wow. That looks like a real game now! |
| |
 [ Log in to reply ] |
| |
|
Michael Drake |
Message #103202, posted by tlsa at 20:46, 29/6/2007, in reply to message #103188 |
Posts: 1097
|
Well that's about the most graphically impressive game RISC OS has seen since Darkwood. Don't forget Destiny, though. Graphics-wise/technically speaking it's perhaps the most impressive home-grown RISC OS game, even if it was let down heavily by only having the monsters rendered facing 4 directions instead of 8 or 12. And no, Iron Dignity doesn't count, because it was never released for RISC OS 
What about BHP? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103204, posted by Phlamethrower at 21:02, 29/6/2007, in reply to message #103202 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Good point - that's probably around the same complexity as Destiny. Perhaps a bit more, since BHP had 3D models moving through the world instead of flat sprites. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #103206, posted by andrew at 22:39, 29/6/2007, in reply to message #103204 |
 Handbag Boi
Posts: 3439
|
I agree BHP was extremely good for the time but Darkwood had far more depth and a detailed 3D landscape (as well as the 2D IF-style high quality gfx). I remember seeing a picture in a book in the 80s showing an imaginary game of some character in a 3D environment walking towards a boat by the shore and I thought that would never be possible and not only was it possible but in1996 and on Acorn machines.
[Edited by andrew at 23:41, 29/6/2007] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103212, posted by Phlamethrower at 10:25, 30/6/2007, in reply to message #103206 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Well I've now decided I'm going to make things look a bit prettier, by implementing the full day/night cycle. Although I was probably going to do this eventually anyway, I've decided to do it now because the current code for storing tiles uses far too much memory. Each tile is 64x64 pixels, 16bpp - taking 8KB of RAM. This itself isn't much of a problem, but the caching system is. To simplify screen rendering I've made the code cache each tile in each of the 4 different rotations (depending on how it's used in the level). There aren't any size limits with the current caching code, so 500 tiles could take up anything from 4MB to 16MB of space - leaving only 10 or 12MB spare for everything else (going with my minimum spec of a 32MB RiscPC). And I've got no idea how many tiles the game will actually need, nor how much space all the other graphics/sounds/etc. will take.
So instead I'm converting all the tiles from 16bpp to 256 colours+palette, and inroducing a proper, size-limited caching system. If the cache is limited to 200 entries (at 8KB each) then it will use up just 1.6MB of RAM. Any tiles which aren't in the cache will use only 4.5KB each. This will allow me to fit over 3000 tiles and the cache into the same 16MB of RAM as earlier. The change will also speed up loading times, since each tile will take roughly half the disc space as before.
And the other benefit of the cache and palette system? It was the only major issue standing in the way of me implementing the day/night cycle (since cars and peds already use palettes and sprite caching). So I thought I might as well take the time to implement it now, and no longer have to worry about whether I'm setting the game in the day or night (or both).
[edit]
And, (I might have said this some time ago), the code for the day/night cycle will also provide me with an opportunity to implement better R/B swapping, that works on swapping the colours in the sprites instead of swapping each frame of the screen. So I'll be able to play the game at full speed and resolution on my Iyonix. Yay!
[Edited by Phlamethrower at 11:36, 30/6/2007] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103421, posted by Phlamethrower at 19:19, 8/7/2007, in reply to message #103212 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Weekend update... OF DEATHdawn
* The day/night cycle is now implemented. This means:
- mission scripts can set what colours are used at each time of day, as well as the length of the day (in realtime) and the current time of day
- the new tile caching system has been implemented, and tiles have been converted to 8bpp palettised sprites
- support for fullbright palette entries has been added - the first N entries of each palette won't be recoloured as part of the day/night cycle. This will be used for headlights, neon signs, flames, etc.
- although peds, cars, and tiles are recoloured as part of the day/night cycle, objects currently aren't as they're still using 16bpp sprites
* The new R/B swapping code is in, so there's no real performance penalty for people who need to use it
* ..and because of this, I have discovered that DMA accelerated rendering (on the Iyonix at least) is almost completely useless, due to the sound distortion problem. Even at low resolutions, or if I only DMA every other frame, or split the transfer up into small chunks with delays inbetween, it still occurs (or cripples the speed so much that it's slower than writing straight to PCI RAM) I may be able to find a way around this in the future, but at the moment it isn't much of an issue since the game still runs at around 25fps at 640x512 
* The map generator has been updated to put named map zones into the map. At the moment the names are just placeholders, but the other informaton (ped and car spawn information) is correct - which means that...
* ... the first version of the ped/car population control code has been written. This means that peds (and in a little while cars) will spawn in the map and wander/drive round doing their day-to-day activites (except they don't wander yet, since they still have no AI). The code will try to keep a constant population of peds and cars around the player, by removing peds/cars when they get too far away and adding new ones just off-screen if the population is too low. It will also keep track of what peds and cars are in use by mission scripts, to make sure it doesn't accidentally delete them, as well as keep track of any peds/cars the player has interacted with (so the player's favourite car doesn't keep vanishing as soon as he leaves it alone for five minutes. Like in all recent GTA games )
So basically the next bit for me to focus on is getting the ped & car populace code working properly, and then start adding the AI. And at some point update the object code so objects can be recoloured according to the day/night cycle. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103423, posted by Phlamethrower at 20:36, 8/7/2007, in reply to message #103421 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Heh... I've just fixed the map plotter to not try and draw tiles that are wholly off-screen, and the framerate has increased significantly  Now I'm getting between 30 and 50fps at 640x512, with DMA disabled (on an Iyonix, of course). This is almost as good as the speed I was getting before with DMA enabled (Although I probably had VSync turned on as well)
I can't remember what the RiscPC's framerate was before this change, but it's now getting 25-35fps at 480x352. Which makes me happy, because I won't have to do any more optimisation for a while  (since both machines are currently meeting/exceeding their target framerates) |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103426, posted by Phlamethrower at 22:01, 8/7/2007, in reply to message #103423 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
...and now cars will spawn (and despawn) as well. Although driving along streets that are full of empty, unmoving cars isn't very easy
Pictoral proof attached! |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #103437, posted by Loris at 13:41, 9/7/2007, in reply to message #103426 |
 Ha ha, me mine, mwahahahaha
Posts: 1025
|
'Day' looks OK, 'dusk' is too dark for constant play, 'night' is awful.
You might get away with night if you provide light sources (ie headlights & torches), or if you can easily sleep though it or something. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103438, posted by Phlamethrower at 14:07, 9/7/2007, in reply to message #103437 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
'night' is awful. Don't worry about that too much - it does look better when it's fullscreen, and those were just placeholder colours I was using to test the system. The real values should look better.
Apart from just scaling the R/G/B values I can also apply offsets to them - that will hopefully give me enough flexibility to create an interesting day/night cycle without making things too dark.
You might get away with night if you provide light sources (ie headlights & torches), or if you can easily sleep though it or something. Light sources is definitely something I'm interested in implementing, but it's hard to know what the best way of doing it would be. It would most likely involve rewriting a fair amount of the low-level rendering code, so isn't something I'm likely to try doing before I've thought it through fully. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #103441, posted by andrew at 19:12, 9/7/2007, in reply to message #103438 |
Handbag Boi
Posts: 3439
|
I think you could replace night with dawn and have orange-yellow hues. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103534, posted by Phlamethrower at 00:13, 16/7/2007, in reply to message #103441 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Weekendy-update thing:
I've implemented the AI framework, so peds will now wander around the level. Initially I was thinking of implementing a very simple system, but then I realised that that would be too simple and would just result in lots of horrible code if I wanted to do anything complex. So instead I've gone for a more advanced system - instead of each ped having a single goal, it now has a stack of goals. This means that potentially complex goals such as "Go from A to B" can be broken down into a series of individual steps, such as "Go from A to C, steal car D, drive to E, get out of car, walk to B". For example, the default "wander aimlessly around the map" AI doesn't actually do any wandering; instead it picks a point to wander to, and then creates another goal which walks the ped towards that point. Then when that "walk" goal is completed it is removed from the stack, causing the original "wander" goal to be processed again (and a new walk goal inserted).
Unfortunately, now that the peds can walk, it's become rather obvious that they lack any collision-avoidance abilities. A potential long-term goal will be to get them to intelligently avoid objects in their path, but for the moment I'm instead trying to upgrade the ped movement code so that peds which try to walk into an object will slide sideways along the surface instead of stopping dead. This is potentially all that's needed to stop the peds getting stuck together in groups of 5-6. Even if it doesn't solve the problem entirely it will still be a worthwhile improvement, as it's something that the player will appreciate, and the code can easily be extended to pass the collision information back to the AI to allow it to accurately plot a course around the object.
I've also had a simple idea on how to improve the day/night cycle, which I'm hoping will result in a more pronounced, somewhat stylised night effect (one which won't involve making the screen too dark to actually see). Once it's implemented I'll have to have a proper play with the code and see if I can get a day-night cycle that I like the look of. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #103535, posted by ksattic at 18:22, 16/7/2007, in reply to message #103534 |
 Finally, an avatar!
Posts: 1291
|
Cool, I'm pretty interested to see how the AI develops. Let us know when you have uploaded a new version for us to try out. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103539, posted by Phlamethrower at 22:03, 16/7/2007, in reply to message #103535 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The improved ped movement code is now working, and (with the exception of sliding along cars being broken) it seems to work quite well for increasing the mobility of the peds.
Unfortunately it isn't a complete solution, since I still managed to find a group of 15 peds stuck on each other. But then I remembered how the peds in GTA can be a bit touchy, so I implemented a second solution - make the peds attack each other if they get stuck for too long. Problem solved!
I think the next area for me to work on is going to be finishing the car code - i.e. finishing the physics model and implementing the damage model. This will allow me to go on to implement the car AI, as well as provide a decent means of transportation for when I start testing mission scripts (since the locations of the missions will be dictated by a future version of the map generator, and so could easily be halfway across the map from me). It's also the last item on the 'big three' list (map generator, AI, car physics).
Let us know when you have uploaded a new version for us to try out. The next version will probably be after the car physics/damage/AI has been implemented. This should allow any potential car designers to test their cars properly (hint hint, help wanted, etc.) This will hopefully be in less than a month's time.
At some point however I am expecting to decide that "enough is enough" as far as "test" releases go. I'll then be working in (near) silence until the game is complete, to make sure the experience is kept fresh for the player(s). Depending on how things go there may be another release before then with near-finished AI (to allow any potential mission writers to start writing missions), but don't be surprised if I make you wait a while before seeing the finished product |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103612, posted by Phlamethrower at 15:46, 24/7/2007, in reply to message #103539 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Post-weekendy-update-thing:
Didn't get a massive amount done last week, but I did flesh out some more of the damage/combat code. In particular, everything is now using the new resistance-based damage system, cars can now be damaged and destroyed, car-mounted weapons work, and you can set peds/cars on fire. Yay!
Today (mainly in an effort to postpone the trickyness that is finishing the physics code), I have discovered The Freesound Project, which looks to be a strong contender for free, royalty-free sound effects for use in game. OK, a lot of them seem to be crap/inappropriate, but with over 35,000 samples available there's a good chance I'll be able to find enough good ones to use. And if I can't find what I want, I may be tempted to buy some sounds from sounddogs, since they resell professional-quality sounds (and have quite a few that I like the sound of). The only trouble is that I'm yet to find any decent engine sounds on both of them - but I may just need to dig a bit deeper, or have a go at reprocessing the samples myself.
The other site I've discovered is ccMixter, which looks to have a good few thousand music tracks for use. Except that a lot of the ones I've listened to so far seem a bit tame in nature, lacking any real "oomph". And there's no prog rock tag  But they do have a ratings system and editor's favourites and things, so hopefully by sticking to the highly-rated tracks I'll be finding the stuff with more meat to it. Plus I can chop off all the boring intro/outro bits, since they all seem to be licensed under licenses that allow remixes. Yay!
But I won't be starting/finishing the physics until I get at least one decent engine sound, because I need that for some simple feedback of how the physics model is driving the engine |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #103613, posted by ksattic at 17:09, 24/7/2007, in reply to message #103612 |
Finally, an avatar!
Posts: 1291
|
If you want engine sounds, I usually find a lot on car websites where people post clips of their modified engines. |
| |
[ Log in to reply ] |
| |
|
Peter Howkins |
Message #103614, posted by flibble at 19:55, 24/7/2007, in reply to message #103613 |
Posts: 892
|
If you want engine sounds, I usually find a lot on car websites where people post clips of their modified engines. All under copyright, unless stated otherwise. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #103615, posted by ksattic at 20:10, 24/7/2007, in reply to message #103614 |
Finally, an avatar!
Posts: 1291
|
All under copyright, unless stated otherwise. For personal use, it's fine. He said he wanted to use it to audibly test the car model. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103616, posted by Phlamethrower at 20:10, 24/7/2007, in reply to message #103614 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
All under copyright, unless stated otherwise. For personal use, it's fine. He said he wanted to use it to audibly test the car model.
With the intention of keeping it for use in the game proper. There's no point me/anyone else spending time hunting for good sounds if I ultimately can't use them.
It's OK though, I've now downloaded enough engine sounds to get me started (and a load of other sounds for the rest of the game).
[Edited by Phlamethrower at 21:12, 24/7/2007] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103620, posted by Phlamethrower at 20:50, 24/7/2007, in reply to message #103616 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Anyone know of any decent (i.e. good+free) sound editors?
All I really need at the moment is something that makes it easy to generate sound loops from a longer sample. So it needs to be able to play loops on-the-fly without any annoying gaps at the start/end of each run through the loop, and if possible provide a way of blending the start/end of the loop together to help hide the join.
Currently, the software that came with my sound card fails on both counts. But mainly it's the slight pause at the end of each loop that's annoying, as it means I can't check if something loops properly unless I paste it several times into a new file. |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #103621, posted by rich at 22:09, 24/7/2007, in reply to message #103620 |
 Dictator for life
Posts: 6828
|
Pretty sure Audacity does that, on a variety of OSes.
________
 Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103625, posted by Phlamethrower at 23:05, 24/7/2007, in reply to message #103621 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The looping is definitely better - but it doesn't seem to update the playback positions as you drag the selection area |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103632, posted by Phlamethrower at 14:21, 25/7/2007, in reply to message #103625 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I have decided that Audacity is crap, because it's randomly padded some of my saved files out to 5 seconds in length by adding silence to the end.
Adimttedly I do need to reprocess most of them again anyway (since Audacity also seems to lack a (simple) sample rate conversion tool), but this "feature" still isn't very helpful since some of the sounds need a specific amount of silence on the end (e.g. footsteps), and the only reliable way of checking the looping of those sounds was through Audacity. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103644, posted by Phlamethrower at 21:37, 27/7/2007, in reply to message #103632 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
After a couple of days of fiddling, I now have a new physics model that doesn't spaz out as soon as you press the accelerator. The breakthrough came when I realised that I was using the location of the car as the basis for calculating the road velocity, when I should have obviously been using the velocity of the car. This would have been spotted a lot earlier if I hadn't switched to using a BASIC program to test the algorithm; a BASIC program which starts the car at 0,0. (Cue lots of confusion as to why the car was rubber-banding back and forth as soon as an acceleration was applied)
Other things that didn't help in the development of this new algorithm included me following a guide that advocated the use of a slip ratio formula that results in 0 slip if the car is stationary. Which basically means that the car can never start moving, since I'm now keeping track of the wheel speeds, and the slip ratio is what's used to calculate how much force the spinning wheel should exert on the ground. (It also didn't help that the original website of the guide is now dead, making it only available through web.archive.org, and the fact that the sample source which I'd downloaded a few years prior uses a completely different slip ratio formula, and a throughly simplified engine model)
But before noticing the slip ratio problem (and the road velocity problem) I concluded that the problem was the function to convert the slip ratio to the traction force, and so tried implementing the Pacejka magic formula (which had me somewhat worried due to its dependency on 11 poorly-documented tweak values per car).
So after implementing that and finding that it was still suffering from the same problems, and not really knowing how to come up with my own slip ratio function that would work properly at 0 initial velocity (presumably not helped by my attempts getting thwarted by the road velocity problem) I then did the sensible thing and stole the (vastly simpler) slip ratio & friction functions from RARS.
So the end result is that I now have a car that drives reasonably sensibly, much like the old physics model. But unlike the old model this one uses a gearbox (although there's no gear shift logic yet), and it also tracks wheel velocities (which is important for things like skidmarks, or letting the car generate high revs when airborne)
I also finished processing the sounds a couple of days ago, and started adding the code support needed for those (as well as fixing various sound-related bugs). So now you get weapon sounds when firing weapons and footsteps when walking. Engine sounds will likely be next, once the new code is merged into DeathDawn. I've also got a list of other sounds that I need to look for, whether from freesound or elsewhere. But I do have a good selection of screams ready |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103825, posted by Phlamethrower at 07:30, 10/8/2007, in reply to message #103644 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I haven't done a massive amount of work over the past two weeks, but I did manage to get the new physics model integrated into the engine, complete with gearshift logic and engine sound. Apart from doing a couple of other tweaks elsewhere, I'm now taking a bit of a break from the physics, and instead looking at improvements/fixes to the map generator. In particular how I can restructure it so that road painting works properly. I've also worked out how I want mission script support to work, so will likely take this opportunity to add that. I'm also thinking about how I can extend it to support hills, bridges, and other multi-level constructions - which I think I may have just found a sensible solution for. |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #103830, posted by Loris at 14:59, 10/8/2007, in reply to message #103644 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
Jesus H.
Haven't you considered having cars that you point and they just go?
I once wrote a 'truck racing' game which had vehicles handling rather like hovercraft. It was rather fun, but I didn't finish it unfortunately. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103832, posted by Phlamethrower at 15:04, 10/8/2007, in reply to message #103830 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Haven't you considered having cars that you point and they just go? Bit simple for a game that's mostly about driving 
I'm just dreading the code I'll have to write (or the concepts I'll have to understand) when/if I introduce articulated vehicles
I once wrote a 'truck racing' game which had vehicles handling rather like hovercraft. It was rather fun, but I didn't finish it unfortunately. There's a 99% chance that DeathDawn is going to have hovercars. Which will be a lot more "point and go" in nature, probably handling more like hovercraft than cars (and will be able to drive across special hover-roads, which regular cars/people will just fall straight through). |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #103862, posted by Loris at 22:00, 10/8/2007, in reply to message #103832 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
Haven't you considered having cars that you point and they just go? Bit simple for a game that's mostly about driving
Well, you're right of course. What I meant was that however complicated it is under the surface, what is important is that the handling is fun.
Realism, accuracy, graphical flair; none of these matter except insofar as they make it more fun. In my experience any game which emphasises one of these (or story, a large level size, or any of several other things) risks being inferior because of it.
But then, I like games like bomberman, super-Mario, katamari, puyo-puyo &c. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #103872, posted by Phlamethrower at 08:47, 11/8/2007, in reply to message #103862 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Haven't you considered having cars that you point and they just go? Bit simple for a game that's mostly about driving
Well, you're right of course. What I meant was that however complicated it is under the surface, what is important is that the handling is fun.
Realism, accuracy, graphical flair; none of these matter except insofar as they make it more fun. In my experience any game which emphasises one of these (or story, a large level size, or any of several other things) risks being inferior because of it.
Don't worry, this isn't going to turn into a full-blown driving simulation. The physics simulation is now on par with the complexity of the physics in GTA 1/2 - and I don't think you'll find anyone who complained that the car handling in those games was un-fun. It's providing me with the scope I need to make a big heavy truck handle like a big heavy truck, and a fast sports car to handle like a fast sports car. And there are enough values to tweak to allow me to introduce subtle or not-so-subtle differences between cars in the same class.
Since I don't have much experiene with vehicle physics, it made a lot more sense for me to look at existing simulations and base my code around those rather than try and build everything impirically (and end up with hovercraft-esque handling like your truck game). Most of the equations still use SI measurement units, which makes my job even easier, as I can use real-world vehicle stats as a basis for the handling of vehicles in-game. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #104221, posted by Phlamethrower at 17:01, 2/9/2007, in reply to message #103872 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I've finally done some more work. Hurrah!
Contrary to the above posts where I said I'd be working on the map generator, I've instead hacked in the basics of the car AI. Although the cars can rarely make it round a corner without driving off-road and getting stuck, I think that with some tweaking the approach I'm using can be made to work.
I've also discovered that OS_File 10 gives about enough throughput on an Iyonix to be able to record video at 320x256x16bpp. As this short video proves:
http://www.phlamethrower.co.uk/misc2/ddcartest.mpg
[edit]
After a bit more tweaking, it (the car AI) is now working a lot better. Single cars can generally drive without any problems, and multiple cars are semi-working too. Apart from adding some proper object avoidance code I think the biggest improvement will come from doing more work with the physics, since it's currently very hard to corner at low speed.
But: Yay! Car AI.
[Edited by Phlamethrower at 19:42, 2/9/2007] |
| |
[ Log in to reply ] |
| |
| Pages (22): |< <
19
> >|
|
The Icon Bar: The Playpen: Slightly cold news on page 10! Phlamey breaks the server. |
|
