| |
Slightly cold news on page 10! Phlamey breaks the server. |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Jeffrey Lee |
Message #72274, posted by Phlamethrower at 19:12, 30/11/2005, in reply to message #72270 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Range checks added, all but 1 of the rendering bugs with sloping block tops/sides fixed 
(Well, apart from another bug, but that's more of a misfeature atm) |
| |
 [ Log in to reply ] |
| |
|
Phil Mellor |
Message #72275, posted by monkeyson2 at 19:43, 30/11/2005, in reply to message #72270 |
 Please don't let them make me be a monkey butler
Posts: 12380
|
Me = Your god. Me = Atheist 
(Although what you can't see there is that the east and west sides of the bottom block are extending onto the top of the alternate screen bank. Which probably explains why trying to plot the top two corner blocks will cause the program to crash Must add some more range checks ) Or just claim a bit more screen memory either side |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72285, posted by Phlamethrower at 01:05, 1/12/2005, in reply to message #72275 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
10 FPS, not too bad. All I need to do is get it 2.5x faster and I'll hit my target
That and change the rendering order so that the blocks don't all overlap. And add some division by 0 safeguards  |
| |
[ Log in to reply ] |
| |
|
James Shaw |
Message #72288, posted by Hertzsprung at 09:22, 1/12/2005, in reply to message #72285 |
 Ghost-like
Posts: 1746
|
Fullscreen antialiasing, please |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72289, posted by Phlamethrower at 11:01, 1/12/2005, in reply to message #72288 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Fullscreen antialiasing, please Just by a small monitor and run it at too high a resolution
The fantabulous plotting algorithm
This algorithm relies on overdraw to produce the correct image. If this algorithm, or one like it, doesn't work well enough, I think my only other option would be to scanline convert everything and use a span buffer before drawing to screen. Which will be a bit tricky, considering some of the sprites will be masked. Note that in this description 'column' is the new name for 'stack2'. A map is a a grid of columns; a column is a pointer to a stack and the base height of that stack; a stack is a vertical stack of blocks; a block is a simple cube like shape that fills a 1x1x1 unit cube.
First things first: Plotting a map without any objects on it. For this we need to plot each column in turn, working from the outside of the screen in. E.g.:
123454321
234565432
345676543
234565432
123454321
Where 1's are plotted first, 2's 2nd, etc. For each column we plot, we just need to plot it from the bottom of the stack upwards. A column with plotting order X will only overlap columns with plotting orders less than X.
A map with objects
All map objects (peds, cars, 'objects') are 2D rotating sprites. This means that prior to rendering, a list of the potentially visible objects can be made:
typedef struct {
gp_spr *s; /* Sprite */
f1616 dx,dy; /* Sprite deltas for use by sprite plotting function (contains rotation & scale info) */
vec16 org; /* Origin in world */
f1616 minx,miny,maxx,maxy; /* 2D bounding box of the rotated sprite, in world coordinates */
} vobj;
For a particular vobj:
* If its origin is below the lowest block in the visible area of the map, discard the vobj
* Or if its origin is above the camera, discard it
* If its perspective-translated bounding box is off the screen, discard it
* Else there's a good chance it will be visible, so we need to work out what block it is inside.
* To be classed as inside a block, its origin must be below the surface level of the block
- This surface level must be calculated using the slope parameters of the block
* Once we have worked out what block it is inside, we can only draw the sprite to screen when:
- The block ('X') below the one it is in has been drawn
- All blocks in adjacent columns (which the vobj bounding box intersects) have been drawn, up to and including the block which shares an edge with 'X' (E.g. if a car is on a flat next to an upward sloping block, the upward sloping block must have been plotted because the edges of the top surface that joins the two blocks are at the same height. This ensures that the car does not appear to vanish partway underneath the sloping surface.)
The last point is the crucial one, and will require another algorithm to make sure all vobjs are drawn in the correct order (i.e. farthest to nearest) without breaking any of the vobj or map block plotting rules.
Map block plotting rules
Taking the top left corner of the first example:
AB3454321
CD4565432
345676543
234565432
123454321
A block in column D can only be drawn if the heights of the tops of the last blocks drawn in columns A, B, and C are equal to or greater than the height of the top of the block we want to draw in column D (Or there are no more blocks to draw in those columns. Which then gets a bit tricky, because there might be further blocks behind A, B, and C which need checking (Except in this case there isn't, because they're at the edge of the visible area of the map)).
So, how are you going to do all that then?
I suspect that a recursive algorith can be used to draw everything in the right order. Exactly what algorithm, I'm not sure
It might be worth calculating the bounding boxes of all objects (vobjs and map blocks) in screen coordinates. Then they can be depth sorted, and the information about which ones overlap can be used to work out what order they should be drawn in. E.g. a simple 'isinfront' function could return true or false if a given block or vobj is infront of another block or vobj; this is all that's needed to apply an order to the list (Since I suspect giving map blocks a discrete Z value is impossible. Although it may be possible to use the length of the vector running between the camera and the block, as opposed to just the Z coordinate of the block) |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72290, posted by Phlamethrower at 11:11, 1/12/2005, in reply to message #72289 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Of course, if I was to fix the base height of each block stack to a single value (Or just a multiple of 1 unit) then calculating which blocks are infront of which will be a lot easier. I think there was no real reason beyond flexibility for me to have a fully variable base height; restricting it to multiples of block heights shouldn't cause any problems. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72305, posted by Phlamethrower at 17:59, 1/12/2005, in reply to message #72290 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I've done the corners-first plotting algorithm (and added the division by 0 checks), so the test map is now rendering properly (As should every other map).
Next step will be to add the ped, car, and object code so that I can get vobj lists and work out how to structure the real renderer. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72310, posted by Phlamethrower at 23:09, 1/12/2005, in reply to message #72305 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*stops messing around with VNC and his 2nd monitor and gets back to work*
Right, the ped sprite and ped definition/type code is done. Still need to do the ped object code though, along with the car definition/type, car object, object sprite, and object-object code.
And then draw/obtain a crap load of sprites to use for testing |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72311, posted by Phlamethrower at 02:17, 2/12/2005, in reply to message #72310 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*tries to make lists of all the bits that go into peds/cars/obj's*
Also thinking of changing the ped/car/obj/ent script variables to work differently (specifically giving each ped, car, obj a linked list of the script vars that reference it. then the script vars can point to their unique entry in the linked list, thus allowing appropriate script vars to be quickly reset to when the ped/car/obj is deleted, as well as retaining fast reassignment of variables to new values) |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72313, posted by Phlamethrower at 12:43, 2/12/2005, in reply to message #70880 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
To allow cars to be recoloured, each car was given its own 256 colour palette. About 32 of these colours were set aside for the car recolouring - 16 for the main colour and 16 for the secondary. The game could change these palette entries to recolour the car. In GTA 2 there were also a few additional colours, used for the head & tail lights. This is a lie
After checking, it looks like GTA 1 & 2 simply store multiple pre coloured palettes for each car. You could either use a car editor to generate the palette from new HSV values, or export and edit the palettes manually. Manual editing would then allow you to "palette hack" stripes, logos, decals, etc. into the game, by drawing designs on the car which are only visible when a certain palette is used.
Also the lights on cars in GTA 2 were done as a seperate delta. I worked out that it would be easier to do it like this too, so that's what the code uses (as opposed to the proposed extra remap section).
Turrets in GTA 2 were completely seperate sprites; gang logos too. However I'm taking the route of using an extra delta for these. The gang logo delta can be applied to the car along with all the other deltas. The turret delta though must be requested and cached seperately, to allow the turret to rotate etc. There will also be special flags on how to interpret the "flashing lights" deltas. E.g. these deltas could be used for gang logos, a constantly playing animation, or the flashing lights when a siren is turned on.
I'll also add support for 'null remaps', i.e. copy the palette entries for a remap block straight from the original palette. This will allow simple palette hacks to be used.
I'm also considering allowing the use of auxiliary palettes - so instead of just specifying the two remap colours, you can also give the base palette ID. This will allow for more extensive palette hacks than GTA 1/2 allows.
I may also have a play around with different algorithms for generating the recoloured colours, e.g. allowing overbrightening, or specifying two colours per remap block.
As long as I stick to 256 colour palettes and caching the resulting images I can do pretty much whatever I want with the cars
Currently though, all the standard remap combinations are listed in the car definition file. These will be used for choosing the colours of the cars that drive around the streets, and after they've been to respray shops. Mission scripts will also be able to provide their own remap definition, so they can set cars to specific colours.
[Edited by Phlamethrower at 12:48, 2/12/2005] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72316, posted by Phlamethrower at 15:11, 2/12/2005, in reply to message #72313 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Also thinking of changing the ped/car/obj/ent script variables to work differently Done.
I'll add support for 'null remaps'
...
I'm also considering the use of auxiliary palettes Also done. The auxiliary palettes are read from the same sprite file as the car sprites - it looks for sprites pal1, pal2, pal3, etc. This is easier than loading them from palette files on disc, because it won't require an extra file (e.g. the car def file) to tell it where to find the palettes.
I've also got the 'marker' sprite working - this (optional) sprite uses colours to mark the coordinates of doors/seats/turrets/etc, this can then be scanned when the car def is loaded to work out the coordinates automatically.
I've also got the header written for the object code, and will flesh it out next. I can then write the vobj code and see how many hundreds of errors have crept in since the last recompile (build #172 @ 17:16:13 yesterday. Yay for automated build number & date generation!)
I also have a simple BASIC file to generate 256 colour palettes, so if anyone feels like drawing some cars let me know and I can give a brief rundown of what sprites are needed |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72324, posted by Phlamethrower at 21:56, 2/12/2005, in reply to message #72316 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*finshes first verison of object and vobj code, starts working through compilation errors* |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72329, posted by Phlamethrower at 01:57, 3/12/2005, in reply to message #72324 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Objects are (just about) working
I also have an idea on how to structure the event/trigger system, so once I've ironed out the bugs with the objects I might work on that (as well as add some more script commands for inspecting/editing objects).
I also need to start wok on the collision detection/movement code soon, but I think I'll get (static) peds and cars working first. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72351, posted by Phlamethrower at 20:24, 3/12/2005, in reply to message #72329 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Objects appear to be working properly now, but there are some rather strange bugs with savegames |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72356, posted by Phlamethrower at 23:02, 3/12/2005, in reply to message #72351 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Bugs fixed, work on peds, cars, and a generic event system has started. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72357, posted by Phlamethrower at 00:26, 4/12/2005, in reply to message #72356 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Generic event system C code done, as are basic ped/car header files. I've also fleshed out the sound system a bit - although it won't load or play any samples yet, enough code is now there to allow peds/cars/objects to attach sounds to themselves and manipulate those sounds.
Also this game now contains more source code than Dark Matter (Although Dark Matter uses more parts of my code library) |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72368, posted by Phlamethrower at 21:09, 4/12/2005, in reply to message #72357 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*wonders where moss's post has vanished to*
*realises what he just said*
Anyway... back to the coding
Working on the ped & car code atm, as well as reworking the object code a bit to support the different behaviours that will be required for different types of bullet |
| |
[ Log in to reply ] |
| |
|
John Hoare |
Message #72369, posted by moss at 21:21, 4/12/2005, in reply to message #72368 |
Posts: 9348
|
*wonders where moss's post has vanished to* So do I. It was my way of expressing interest. It's bloody irritating when posts just disappear. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #72370, posted by adrianl at 21:37, 4/12/2005, in reply to message #72369 |
Member
Posts: 1637
|
*wonders where moss's post has vanished to* Maybe the server's full. I wonder who could have done that? |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #72372, posted by rich at 23:56, 4/12/2005, in reply to message #72369 |
 Dictator for life
Posts: 6828
|
*wonders where moss's post has vanished to* So do I. It was my way of expressing interest. It's bloody irritating when posts just disappear.
I wouldn't just delete it. Unless you were using someone else's account to post 
Plus I haven't been online much today...
________
 Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72373, posted by Phlamethrower at 00:20, 5/12/2005, in reply to message #72372 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
It wasn't even deleted properly - he was still showing as having made the last post, and it was still appearing on the threaded list.
The ped and car code is nearing a compilable state |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72378, posted by Phlamethrower at 17:17, 5/12/2005, in reply to message #72373 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Hmm, drawing good looking cars doesn't seem too difficult. Except for the bastard doors, of course 
*does the other door, then starts on some ped sprites* |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72381, posted by Phlamethrower at 18:00, 5/12/2005, in reply to message #72378 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Hey, drawing peds is easy too
They're so small that you don't need to bother making the shading look perfect. Just throw a few different shades of colour on in the rough shape of a person and you're good to go |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72387, posted by Phlamethrower at 18:36, 5/12/2005, in reply to message #72381 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*gets bored drawing peds and just reuses the same frames for several different animations*
Right, now to see if this actually compiles |
| |
[ Log in to reply ] |
| |
|
Ian Cook |
Message #72391, posted by ilcook at 19:30, 5/12/2005, in reply to message #72387 |
 Resident idiot
Posts: 1077
|
*gets bored drawing peds and just reuses the same frames for several different animations*
Right, now to see if this actually compiles Well has it, compiled?
[Edited by ilcook at 19:31, 5/12/2005] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72394, posted by Phlamethrower at 19:43, 5/12/2005, in reply to message #72391 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Not yet, I stopped to eat
There's a bit of code I need to rewrite, but then the rest of it should just be syntax errors. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72397, posted by Phlamethrower at 20:16, 5/12/2005, in reply to message #72394 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
It compiles now
*tries running* |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72398, posted by Phlamethrower at 20:37, 5/12/2005, in reply to message #72397 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Peds will load and spawn but aren't being drawn, and trying to load a car will corrupt the heap |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72399, posted by Phlamethrower at 20:46, 5/12/2005, in reply to message #72398 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Hang on - I was looking in the wrong corner of the map
He seems a bit small though. And the animations aren't working |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #72400, posted by Phlamethrower at 21:14, 5/12/2005, in reply to message #72399 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
And now, a similarly shrunken car
Looks to me like I've got the scale factors wrong, and all sprites are being plotted at half size.
 |
| |
[ Log in to reply ] |
| |
| Pages (22): |< <
5
> >|
|
