as collected and (very little) formatted by addie walti
The start of a thread is marked with 0- (because sometimes the order is reversed)
remove internal object
Int object . length&file size
limits
dup 62000 (trackfile size)
(monza 99 of Dan C) banking
track no loading
banking(with
rumble strip)
First Corner (CC-line trouble)
Track width question
Underlay Bitmap
editing the horizont jam
0xc5 a4: New Location Code D!
a8 of 0xc5
Interest in an object-tutorial?
view-distance cmds. new location code
type E
Venetian blind corruption (thin stripes
across the screen)
0-Posted by Adalberto from 62.10.70.112:
Hi guys
we know that it' s impossible remove the internal obj with the track editor of Paul
Hoad , someone can tell me if it' s possible make this with the editor of Iso H.
???
thanks
Adalberto
PS: Paul if you have a solution please help me :o)
Posted by Fat Rat from 207.194.25.212:
Hi Adalberto
Why remove ?, just rename .
Choose a track with the fewest objects , rename all those objects .
Or are you going for a objectless track ??
Just a thought
Les
Posted by Bob Culver from 206.173.174.132:
Which track has the fewest internal objects?
Posted by jason hope from 207.253.108.70:
hungary or portugal
i think!
jason hope
Posted by Fat Rat from 207.194.25.59:
Hi all
fewest object , off the top of my head maybe magny cours.
I know it has zero trees or bushes .
Les
Posted by addie from 194.191.82.13:
f1ct06 has very few also and those are pretty much recycleable :)
Posted by David Richards from 202.12.71.11:
Had this prob retro-fitting Bathurst track - stripping it of bridges, flyovers etc.
In the end I just removed the object commands that place the objects, and leave the
definitions alone.
You can then simply replace unused objects with any new ones you need (like extra
billboards).
Regards,
David
Posted by Adalberto from 62.10.70.48:
why rename ,I think that remove is better ,I must replace an obj that have a big
size with one that is really a lot smaller (2440 with 1060 Kb ) .
If the remove obj work I can rebuce the track and add a lot of usefull command .
....so the track editor of Iso work or not on this subject ????
let me know.....and thanks for the help
Adalberto
PS: Iso ,if you have a solution please help :o)
Posted by jason hope from 209.104.76.93:
i don't see the problem, i've just removed some internal objects, and the track workes
fine. I don't know why you guy's say we can't remove objects from the objects tree...
jason hope
Posted by Paul _Hoad from 212.2.17.129:
Removing objects is dangerous stuff but from what I remember if your very careful
(and lucky) you might be able to replace an object with a smaller one and get away
with it!
be careful though as I don't move the memory pointers of the internal objects...
this was always stuff at the edge of what I knew and there interal objects were packed
with unknowns and it all got pretty hairy in my code!
Paul
Posted by Adalberto from 62.10.72.4:
I know that you can remove or replace an internal obj ,but
when you delete it the size of the .dat file don' t decrese , ..this is "my"
problem.
....by the way , someone can tell if the track editor of Iso H. work fine ????
thanks
Adalberto
Posted by Jason hope from 209.104.76.93:
oh, i get it know...i have not used Iso's editor, so i can't tell you what you want.
Sorry...
Jason
Posted by Iso-Hannula from 130.233.249.36:
Well, it seems that you wait for my opinion...
First of All: Please call me IH or Iso-Hannula or whatever. My first name is Vaino
and Iso-Hannula is last name. So now you must understand why Iso sounds so fun. Please.
I haven't examined that object stuff much. It is maybe the most complex thing in
trackfile. I know all points that should remove if want to remove internal objects.
And I could do that too. But I haven't made it because I can't make NEW objects.
It would be quite bad if one can remove objects with my ed, but can NOT add. But
if you really need this kind of method, I'll make it.
But I'm very busy now, so wait another two weeks... after Christmas maybe.
Vaino Iso-Hannula
PS: Someone said that he hadn't used my editor. I prefer you even try it. I think
it is much more easier to edit track layouts & cc-lines with my editor. But I
know that this scenery business is very difficult (not impossible). Please, try it
and give feedback.
Posted by Bob Culver from 206.173.174.168:
Iso, From all of the messages that I've read, it seems as if you possess a good ability
to understand a lot of the basic coding in GP2. It would be wonderful if you could
use your talents to determine why there is a limit to the length of the circuits
that we can end up making. I don't know if you are aware of this, but track files
of a certain length will not load in the game. Perhaps there is some sort of code
which limits file sizes or data size. This could be a self imposed limitation because
recall when GP2 came out, it was designed to run on upper end 486's as well as the
early Pentiums. All of the TE community will build digital monuments to you at our
tracks if you could find the key to this mystery.
Posted by Iso-Hannula from 130.233.241.41:
Well.. thanks. I'm appreciated.
The truth is that I'm not good at asm-codes. It is very hard work to find out gp2.exe
construction. We know some things there, but finding some limit and changing it is
nearly impossible. For me.
I know very little of limits. One of the few exact knowledge is that 128 is max scenery
cmd. And world limit is 256x256. If we want to find limit location in gp2.exe code,
we have to know exact limit.
If we try to change trackfiles... Is there maximum length of file? If we remove internal
objects, would it help to make longer tracks? I haven't tried, but if someone has,
tell me.
But it might be worth exploring.
Does anyone know is it limit of total file size or trackdatasize or total length
of track limit or what limit? If You know surely that it is NOT one of these, tell.
(see next topics for more info on this subject)
0-Posted by Fat Rat from 207.194.25.66:
Hi All
I'll start with saying , how refreshing to see somewhere,
with a " productive " disscusions .
1 Removal of objects , OK Adalberto's ,reason for removal . Yes this is one parts
of handling the dat file size limit ( needs to be addressed )in combination of efficent
scenery cmds, # of veiwing cmds , basically any & all cmds , Even as far as limitng
the # of letters in the jam file names ,
Yes each & every byte ads to this size & as Adalberto says the sizes of the
objects themselfs and even the number of digits in the boxes for each parameter of
every cmd .
I don't think that removal is impossible and now with a little more though ,
I think the main trouble was the TE's handling of the object numbering , remember
when objects ( definitions, too I think ) were taken out of anywhere other than the
last one listed , the object definitions numbering got all crossed up. THerefore
renaming & importing above the last listed in the tree. Highly recomended over
removal . I think that's what Paul is recalling .
2 The dat file size limit , like the length limit are in the ExE.
I know of 5 of you who have seen inside the exe , IH , Paul, Frank Arenet & Rene
Smith, and PK of Belini.
I talked with PK recently .
re the file size problem . I think he mis understood it as , the length limit.
I know I've read that Frank or Rene had seen the line in the exe,
Reserve mem for .dat file @ 60 KB , or whatever we desided the ture # was, I enquired
if there is a difference with any of the 16 schedule "slots" . No real
anwser on either. I belive it was no on the slot's ( all the same )& hadn't the
line at 60 kb .
I think this limit is just a bit more important , than the track length one . Both
would be nice ( much much more important that setups )
As the dat file size . can effect any & all tracks ,
( short ones fat ones tall ones.. , Spill wine .....) sorry couldn't resist
I don't the any of the art work effects this at all , as the jams & pcx ,snds
all that is loaded into the remaining mem on it's own .But doesn't mean it's unlimited
, but obviously there is much much more available , ram , on gfx card mem , everyone
is running ove P266 , 32mb ram , 16mb vid mem , onboard snd mem, etc .
Possibile to make use of any of this mem we now have , not asking for 3Dfgx of 16
mil .
Just can we increase thte allowable limits for all 4 eliments. 6196 b dat file size
( pretty close ) Ithink 1.4mb sample.cat file size , around there some where .
I had to take all snds above # 33 out , to stay under the total file size limit ,
did remove any just loaded nil .wav at 1 byte into #33-99 still cost 66 b but it's
the safe way . doesn't really matter because like jams each snd has it's own distinct
limits . either time that the game played it , to sample rates , stereo , doppler
, pitch bend transpose etc,etc,
then the artwork limits from max palettes to dimentional size to mem & file size
etc etc
And then finally the Holy Grail of all the track length & world size . I dont
think that this is nescesarly a mem , file size limitaion per say .
more of a gameplay , CC , collision & phyisics limit & likely out of reach.
So maybe in the new year these wise 5 and any other real coders out there can team
up & or contact each other on some exe exploration & experimentation .
If you see reserve 60kb for dat file size change it to 75 & see if it runs ,
If yes , try 99. if it doesnt try 61 . if that does run can't be done .
As you all know I'am not the one to do it , I'am just dipping my toe into java scripting
. wouldn't know an exe with a flashlite & my head stuck up my ... ..
going on 6 years & still advancing congrats to GP2 & yea US .
Keep on
Les
0-Posted by Paul Hoad from 212.2.17.129:
I've seen some code in GP2.exe that does the following
dup 62000 this basically mean
duplication 62000 this is the
space reservered for the track
I don't know if we could change this and I'm not sure
this would overcome the track
length limit which I believe we should not confuse with the
file size limit...
Paul Hoad
Posted by µartijn from 145.94.124.79:
Isn't there some "dup 1597" line in there too??? That would be the length
limit. Please, could you have a look?
And patching this value with a larger one is, IMHO, an experiment that could be VERY
rewarding!
Posted by Paul Hoad from 212.2.17.129:
I think the dup 62000 is just the disassembler saying there is a block of 62000 spaces
all filled with 0
I don't think that we can just add more spaces as this would move some of the other
code to a different location then all the call,jmps and offsets would be wrong...
I'm not sure we can do anything.
Microprose told me Geoff writes these games mainly in assembler (which is pretty
scary!) it could be he has reserved space in the code for the construction of objects
and for caching the current track. That might mean that it would not be possible
to alter these spaces without major pain....
its quite possible however that geoff does do other constants like this that allowed
him to git in all his tracks... (non were near 62000) and anyway there might be a
hard limit of 65535 anyway!
Paul
Posted by addie from 194.191.82.13:
why not simply giving it a try with say 63000 ? i could deliver a dat with more than
62000 bytes in a minute. adalberto probably even faster ...
maybe this value 62000 is arbitrary (something above original monacos 57k, but below
64k) and maybe it just gives the amount to copy (DUPlicate ?!)
1000 additional bytes would give space for 1 simple-building-object and 20 tracksectors
...
Posted by Bob Culver from 204.151.114.9:
The reaction of the PC for the track length limit and file size are different. If
you try to load a .dat file that is 62000 bytes or larger, you receive a "wrong
file type" message. 61999 byte tracks load and run just fine, so the dup 62000
command could be the answer here. Track length is not so obvious. If your track is
too long, the program gets hung up trying to load, but no message is displayed.
Posted by Dan C from 142.58.213.83:
I found that the track length and track file size are independent also.
The track length limit around 7 km I think, thats with little objects or scenery
and file size 62 kb.
After the track was stretched to ~ 7km, the next limit was file size ~ 61/62kb.
Does anyone know of a hacking program that can disguise or hide the file size recognized
by the computer.
I think I saw one a while ago. I not sure if it was cfa.exe. But maybe was can disguise
a file
to be 60 kb instead of 80 kb. But I'm not sure if the game has its own way to recognize
file size, or if
it just accepts what the computer 'sees'.
Dan C
Posted by addie from 194.191.82.13:
to make myself more clear:
paul, anybody who spotted the “dup 62000” in the gp2.exe, could you replace it by
“dup 63000” for a try ?
or is this completely useless and weird ?
0-Posted by Ed from 212.159.3.211:
I noticed that the only time the CC cars are on the banking is when they've been
involved in a collision. Could this mean that there's the possibilty of messing around
with something that puts them on banking? Probably old news to everyone, but...
Posted by Dan C from 24.113.31.229:
Yes, this is something we can't do much about.
From what I've read, the banking command was not really completely developed.
cc-cars only appear banked when they're in trouble. That is the same for bumps.
Thats also why its not as steeply banked as the real one. It would be too hard to
see other cars and unsightly. And I couldn't have a banking track with no banking
at all either.
But I guess that's why there are not many steeply banked tracks for GP2.
I initially had the banking much more bumpy, sometimes exiting the banking in more
than one piece ( I think this could happen if today's cars actually drove on it).
But I noticed that only the player car was affected and slowed down.
The cc-cars were not affected and had an unfair advantage in the race.
Posted by µartijn from 145.94.124.79:
No, it's the same as with kerbstones: a Ccar has 2 modes: stupidly follow the CCline,
ignoring kerbstones and banking. And a mode where the physics model is calculated
for the CCar. Cars can jump, stuble over kerbstones, and go banking.
This was probably done for performance reasons. Anyway, the switch for the modes
is, I guess, a diversion from the CCline because of contact, or the influence of
another car.
Perhaps this switch is adjustable, but I don't know how and where.
Posted by Bob Culver from 159.37.7.57:
Is there any logical organization for commands? If so, maybe some of the unk commands
organized with the bank command that remain to be de-bugged are unused cc bank commands.
A similar occurance exists with bumps. If you construct bumps by using short sections
of track, the cc's are not affected by them, however if you create bumps with the
bumps tables they are.
Posted by Dan C from 142.58.213.83:
Right, I noticed that too.(2 physics modes)
It must be due to performance reasons. It would be nice if there way a way to always
have this 2nd physics 'always on' for cc cars.
Posted by Bob Culver from 204.151.114.9:
I don't think it is done that way on purpose. The bank commands appear to be a feature
that was scrapped, due to pressure to get the game on the market. Possibly something
that will be rectified in GP3. The 112 cc line command could have been the start
of attempting to create a cc line for banked curves. I seem to recall (I can't remember
who discovered it) that the 112 altered the radius somehow, so maybe Geoff was just
starting to finalize how to display the cc's in a banked mode, but had to stop.
I also discovered when making Reims, that I couldn't seem to get the sharp radius
hairpins banked.
Posted by addie from 194.191.82.13:
bob i’m afraid i have to oppose. the bump-table bumps unfortunately dont affect the
cc-cars neither. i checked that out with your reims track.
and the cms112 cc-line sectors are cc-line sectors with simply two radii. one at
the beginning of the sector and one at the end of the sector. the part between the
two ends has transition radii ...
if somebody want to have a look at cmd112 cc-line sectors you may want to have a
look at my bern-grauholz for the extended application of them. they are in every
corner there and almost all of the last third of the cc-line is made by cmd 112 cc-line
sectors exclusively ...
Posted by Bob Culver from 204.151.114.9:
Well Addie, you got me on the bump tables. I had assumed that they affected the cc's,
from all of your research. Regarding the 112 command, my thought was that this was
the start of trying to get the cc's to bank, but it wasn't finished. Does the 112
command do anthing that could not be done with multiple 80 commands?
Posted by Nic Prins from 216.226.215.152:
A cmd112 cc-line sector doesn't do any more than a series of of small cmd80 sectors
of increasing radius, but you don't want to use too many cmd80s otherwise you might
exceed the max number of cc/pit radii. In that sense it is better to use cmd112,
but in all of the cc-line updates that I made a few months ago I used a number of
cmd80s per corner so that the cc-line allowed the cc's to accelerate out of a corner,
unless there was already a cmd112 in place that was close enough to what I wanted.
I only did this because I found it easier to predict the effect a change in the radius
value in the TE of a cmd80 would have in GP2. There was also something different
about the way the TE adjusted the displayed angle value as you made changes to the
radii of a cmd112 sector. I can't quite remember what it was because I haven't used
the TE for quite a while due to exams and a dodgy computer.
I don't think that it makes much of a difference to the drivability of a track whichever
method you prefer to use. The important part is the accurate placement of the line.
0-Posted by Jose Kaplan from 200.211.39.144:
Hi guys.. its the first time i post here but i made many tracks (never released)
before.. Im working on a track based on Zapparolis's Argentina, but it dont load
in the game... everything looks fine and it past the sanity check, but when i want
to try in the game it freeze on loading screen....
thanks,
Jose Kaplan (the same from the old carsets and cockpits, hehe)
Posted by Bob Culver from 204.151.114.9:
There are several possibilities. Track too long and duplicate jam ID's are primary
suspects. I have also had tracks with custom objects that have caused problems trying
to load the track.
Posted by JK from 200.211.39.158:
the track is 2.4 long (2.9 with the pitlane) so no problems with too long track or
so.... and i didnt include any new jams or objects.. thats why i think it sounds
strange...
Posted by Bob Culver from 159.37.7.57:
Check your heights. If your track goes all uphill, and no downhill, you have a big
cliff where they meet. I seem to recall that if that difference was too great, that
would also cause the track not to load. Check your cummualative heights at the last
segments. It should be as close to 0 as possible.
Posted by JK from 200.211.39.137:
I loaded some old backups and found out that the track stoped working after i used
the "creat cc-line" option.... it never happed before to me... still sounding
strange...
Posted by Bob Culver from 192.246.108.36:
At least you followed Rule #1 in Track Editing.....back up your tracks and back up
often. As wonderful as the TE is, it is still technically a beta program and has
some bugs. Which version of the TE are you using?
Posted by addie from 194.191.82.13:
“create cc-line” ?
so you probably have too many curved cc-line sectors now ! there is a limit at some
70 - 80 ! you also have to add the curved pit lane sectors !
Posted by JK from 200.211.39.148:
Addie,
I played a bit with the track curved sections and tried again to creat the Cc line,
and now it works fine....
thanks for the help
Posted by Joel Rhodes from 206.170.184.73:
Just wondering if it is possible to bank the cars with rumple strips on tracks like
Banked Monza and Daytona? I noticed in the game that cars in banked turns only bank
when they hit a rumple strip. After that they flatten out. So my idea would be to
put a rumple strip all the way up the track. It might sound noisy, but at least you
would know where the cars really are.
Correct me if I'm wrong!!
Posted by jason hope from 209.104.76.93:
the kerbs are located on the outside of the track, and therefore a crossover is impossible.
sorry to dissapoint you!
jason
Posted by RPM from 206.170.184.66:
So the rumples have to be outside the track? I got to thinking, maybe if you make
the track the apron, then maybe the rumples could be extended out for the real part
of the track. Then put some differant textures on it and run the CC on it. I am dumb
when it comes to track editing, but there must be a way before Indy comes out next
year! I have seen some pretty amazing things done with games for the past couple
years. You guys have proved that!
Posted by Martijn from 145.94.124.79:
I tried this once, (believe it or not), and it does not work. First of all, the CCars
ignore kerbstones anyway, as long as they are "on-line". Second, the player's
car behaves really, really strange on a large kerbstone, it's not controllable at
all. Third, WHEN the CCs "go physics", they go nuts as well. Definately
crash out.
So sorry, good thinking, but it doesn't work.
Posted by Bob Culver from 192.246.108.35:
I seem to recall that it was possible to change the adhesion of the curbs. If you
could increase the adhesion, then a Nurburgring Karoussell Bank would be possible.
Posted by David Wortley from 212.159.3.211:
I am having trouble making the CC line for my track, I have deleted it all and insert
four sections, 2 are straight, one easy left, and another straight. What ever distance
I make the CC corner from the Start/finish line, the line just keeps on going straight.
Help Me please?
David.
PS If anyone has any descent pictures of the Norisring Circuit,I would very much
like them
Posted by Erik Reinhard from 194.83.240.23:
Hi All,
Currently, I'm working on a little project to render GP2 on three screens (because
our motion pod has three screens, two of which are currently not used). For this
I need a thorough understanding of the GP2 file format. The aim is to convert GP2
files to something like VRML.
My first humble beginnings have started with Paul's track editor (especially the
debug output, which seems to give most of the data that I need.
Unfortunately, it does not seem to provide me with some essential details. The main
one that is bugging me, has to do with initialisation. I would like to find out what
the initial values are for things like track width, altitude, X and Y coordinates
of start position.
Does anybody have any idea how to get to this information?
Any help greatly appreciated. Track editor source would be even more appreciated!
(Please?)
Cheers,
Erik
Posted by Paul Hoad from 195.92.194.13:
Sorry Erik, I didn't reply before does any of this help...
given this as the function that reads the tracks...
void GPTrack::ParseTrack(CDocument *pDoc)
{
setValid(TRUE);
ReadOffsets(pDoc);
ReadTrackObjectDefinitions(ListObjectOffset,TrackDataOffset);
int EndOfTrack = ReadTrack(TrackDataOffset);
int EndOfPitLane = ReadPitLane(TrackPitLaneStart);
int EndOfCCLine = ReadCCLine(EndOfTrack);
CameraOffset = EndOfPitLane;
int EndOfCameras = ReadCameras(CameraOffset);
int EndOfSetup = ReadSetup(SetupOffset);
int EndOfVariousData = ReadVariousData(EndOfCameras);
ReadJamFiles(EndOfVariousData);
createTrack(NULL);
}
This should give you some offsets you can use!
void GPTrack::ReadOffsets(CDocument *pDoc)
{
int offsetstart=0x1000;
LargeNumber1.SetValue(ReadPCDWord(offsetstart));
offsetstart+=4;
LargeNumber2.SetValue(ReadPCDWord(offsetstart));
offsetstart+=4;
CheckSumOffset = ReadPCDWord(offsetstart)+0x1020;
offsetstart+=4;
ListObjectOffset = ReadPCDWord(offsetstart)+0x1020;
offsetstart+=4;
TrackDataOffset = ReadPCDWord(offsetstart)+0x1020;
offsetstart+=4;
SetupOffset = ReadPCDWord(offsetstart)+0x1020;
offsetstart+=4;
TrackPitLaneStart = ReadPCDWord(offsetstart)+0x1020;
offsetstart+=4;
NumberOfObjects = ReadPCDWord(offsetstart);
offsetstart+=4;
}
int GPTrack::ReadTrack(int offset)
{
int gripLevel = 0;
TrackStartAngle.SetValue(getTrackDataWord(offset));
offset+=2;
TrackStartClimb.SetValue(getTrackDataWord(offset));
offset+=2;
TrackStartY.SetValue((short)getTrackDataWord(offset));
offset+=2;
TrackStartZ.SetValue(getTrackDataWord(offset));
offset+=2;
TrackStartX.SetValue((short)getTrackDataWord(offset));
offset+=2;
TrackBeginWidth.SetValue(getTrackDataWord(offset));
TrackWidthLeft=TrackWidthRight=TrackBeginWidth.GetValue();
offset+=2;
TrackUnknown1 = getTrackDataWord(offset);
offset+=2;
......
}
This should get you the beginning positions you required
Paul
Posted by Bob Culver from 206.173.161.140:
To get my next track accuarate, I must use the underlay bitmap feature. I can load
the bitmap, but it always is too small in the upper left hand corner. If I zoom in,
the track of course also changes scale. Is there a way to change the scale of the
underlay bitmap without affecting the track section display?
Posted by µartijn from 145.94.124.79:
Yes, use the "misc config" to set the upper left and lower right corner
of the bitmap.
For an elaborate description, see Addie's
"How to Make an accuate Track.." from:
http://emme.asit.ch/~addie/tutus.html
Posted by Bob Culver from 206.173.161.140:
Thanks Martijn, it works like a charm!
Posted by Augusto Dewey from 200.16.224.249:
I have a problem with this point, maybe i am missing something? I have not problem
with the rest of the jam files, but with the horizont file it always is corrupt after
the edition. IF someone has experience with this, please tell me
Posted by Fat Rat from 209.53.102.62:
Hi Augusto
Yes , common . skies & horiz are a bit tricker than any others .
Watch for palettes , make sure that your are at or under the number of colors in
the original jams
Have fun
Les
Posted by addie from 194.191.82.13:
augusto, did you work with the jameditor of mal ross from the open source project
?
if not, you may want to check it out.
addie
Posted by Roland from 62.108.6.154:
I do some editing on this subject.
I use horizons from GPL in GP2 and never have a prob with it.
I just use the jam editor for it but what can be a prob
is if there is no green in the textures.
What some times happens is that if you use someones textures and extract them from
a horizon jamfile (or any other) and put them in yours that you will see purple in
the game
then just change to color of what should be transparent to the right green.
Roland van Haren
Posted by Mal Ross from 195.92.197.37:
Hi all,
I think the problem is that the JE is trying to be too clever. Whenever you import
a bitmap into a texture, or change the height/width of a texture, the JE will automatically
set the values of 3 of the texture's Flags. The flags it sets are:
Flag 4 = Transparency
Flag 9 = Don't optimise height
Flag 10 = Don't optimise width
It appears that our understanding of flags 9 & 10 (or my understanding of them,
at least) is incorrect and that the JE is not setting them correctly all of the time.
Most of the time, it's fine, but the horizon JAMs have values for flag 9 in them
that I didn't expect. Therefore, whenever you import a bitmap into one of the horizon
textures, flag 9 is turned off by the JE and I think it's this that is causing your
problem. Until I get a new release out (see my next post), you will have to turn
on flag 9 after importing into one of these textures.
Sorry for the inconvenience,
Mal.
Posted by Mal Ross from 195.92.197.38:
Oh, and one other thing...
I'm pretty sure that the number of colours in your bitmap has *nothing* to do with
the problem, Augusto. If you use the Jam Editor, you should be able to use up to
the full 256 colours in *any* JAM/texture. :)
The only reason people often say that you can't have more colours than in the original
texture is that this was once thought to be true. Trust me, it's not. :) However,
GP2JAM and GP2Edit still impose this restriction.
Cheers,
Mal.
P.S. If Steven Young is reading this, *please* can you remove the restriction? GP2Edit
is a _fantastic_ program, but the JAM-related functions are more restrictive than
they need to be. :)
0-Posted by Dan C from 142.58.209.105:
Hi all,
I've been researching the a4: argument in the 0xc5 command that lets you see other
sectors of the track. Basically works like Location types A,B and C.
So, converting the values to binary and looking for 'switches' for each digit, there
are 16 potential switches.
Here is what I found for values of A4:
decimal #(A4)
Switch #: 1 - grey road(no texture) 1
2 - ? 2
3 - fences/walls 4
4 - ? 8
5 - road 16
6 - verges 32
7 - banks 64
8 - all ribbons 128
9 - pitroad 256
10 - pitroad lines 512
11 - ribbon 1 1024
12 - ribbon 2 2048
13 - ribbon 3 4096
14 - ribbon 4 8192
15 - ? 16384
16 - n/a too high value x 32768
I discussed this with Addie and also was confirmed, maybe to call this a new location
code Type D?
I will eventually work on the other unks in this command too.
To Paul Hoad:
Maybe in a future editor release, instead of having to input a decimal number for
the a4, we could have 'check boxes' that we could click on and off for each texture.
It may make thing easier for those unfamiliar with location codes.
What do you think?
Dan C
Posted by Bob Culver from 206.173.161.78:
Great research Dan. I did some further checking. On Reims when you go over the hill
on the back straight, as you crest the hill, I used the Oxc5/Oxc6 combination to
enable the view all the way to Thillois. I used 224 for the A4 value, simply because
it worked for Imola. But, The road texture didn't show up. For people that use the
cloud texture, this shows up as a black strip "bug". I tried just using
128 and that didn't work. What it did was enable ribbons 1,2,3 and 4 only...no road,
no verges, no banks. So, 224 is 128 + 96. The verges are 32, the banks are 64. So,
when I used 224, all of those ribbons show up. Since the road texture is 16 from
your research, add 16=240 and.......everything shows up!!!!
So, for those of you who have sent me e-mails about that bug, go into track section
132 and replace the A4 value in the Oxc5 command with 240. BUG SMASHED!! Thank you
Dan!
Posted by Dan C from 24.113.31.228:
Oh yeah I forgot, if its not already known, Cars and Objects are always seen with
his command, even when A4 = 0.
I think I used 244 in Monza, which switched on everything minus the 4,2 and 1 which
are not really functional anyways.
Posted by Bob Culver from 206.173.161.177:
I also discovered that if the sections specified in the Oxc5 and Oxc6 commands overlap,
when you are in the overlap section, nothing shows up, not even objects! What I am
referring to is in the Oxc6 commandd, the values define the distance that the Oxc5
is inacted. The Oxc5 defines the distance from the S/F line. So, if those two sections
overlap, that is where everything shuts off. For people using tracks with oxc5 and
Oxc6 commands such as Imola and Spa, if you leave these commands in, it could cause
these sort of problems if you are substantially revising the track. I also experimented
with multiple Oxc5/Oxc6 combinations. What happens is the last command is the one
recognised.
Posted by Dan C from 24.113.31.225:
For multiple arguments, you mean:
0xC5, 0xC5, 0xC5, 0xC6 in order. I found that the last one works too, but only for
objects, I think. So, an object would not show up unless it was in the last C5. In
Monza, trying to fix the view of the S/F straight, I have to split it into 2 commands,
since there is a problem of using 1 command to go past the start and end of the track.
Since the pit building is defined in the last sector of track and corresponds to
the first C5, the building does not show up.
For the overlap, you mean when C6 value lies within the values for a2: and a3: of
0xC5?
Posted by Bob Culver from 206.173.161.141:
Yes. Since the A2 of the Oxc6 command determines the distance from the point of the
command that the Oxc5 section defined is visible; if the area defined by the Oxc5
is within that distance, then that is the point where everything shuts off. Since
the Oxc5 defines the section as distance from the S/F line, it is not so obvious
until you actually drive.
Posted by addie from 194.191.82.13:
well done dan ! and thanks very much bob !
i will include the new location code table and your experiences with 0xc5/c6 in the
cmd-lib !
any specific idea on a8 of 0xc5 ?
addie
Posted by Iso-Hannula from 195.197.160.42:
Any idea, why there are two different number of parameters? 7 or 8.
Any sensible reason?
Posted by derek from 205.200.28.46:
I have a question, when I put oxc5 and c6 into the nurburgring, I get very nice views
of the other parts of the track that I define in c5.
But looking bact to the start finish line from the other side of the track, I see
everything except the pit building, tried all the different values in a4, but nothing,
do I have to define this seperatly with its own c5 cmd?
Also when I put c5 and c6 into Suzuka, and it doesn't matter where, the track will
not load. The same is true for spa, (but I only tried it once there).
By the way, I have Belini 99 and they make extensive use of c5 & c6, especially
in sepang, and their a4 and a8 values are -64 & -32768.
Thanks,
Derek Hicks
Posted by Martijn from 145.94.124.79:
Where is the pitbuilding placed? In the pitlane? Then move it to the track, else
it won't show up in the same "window".
BTW some locs define pitlane, according to Dan. Can this not be used to create the
"pitlane along the track" some of us wanted??
Posted by addie from 194.191.82.13:
derek
as for the suzuka-track: this track is set to have 7args-0xc5 cmds. you had to go
to the confic section in the track tree. there you go to “track sections” and to
the position where the pit lane side switch is. there you see the figure 7552. change
it to 8064 and you can insert cmds 0xc5 without trashing the track. (see command-library
for more information)
just in case you are looking for the “other” lane when you are in front of the bridge
at the crossing, it goes “underground” :)
to see it, you also had to adjust the heights there ...
addie
Posted by Derek from 205.200.28.46:
Thanks Addie & Martijn, solved the problem with your help. With Suzuka, I was
trying to see the s/f strait from turn 2 through the dunlop turn, and now you can,
looks great.
Thanks, Derek
Posted by Dan C from 24.113.31.225:
Regarding the pitlane road value, I am a bit shaky about this. I know for sure you
can see the entrance and exits road of the pitlane, bit I did not experiment to see
if you can see the WHOLE pitlane, even with the important verges. So, maybe someone
can look into this.
Also, about the 4 unknowns, from what I tried, I think the first 2 unknowns behaves
differently than the others. Its kind of like a4 in ways ...
Dan C
Posted by addie from 194.191.82.13:
for making the pit lane visible. maybe the regular pit lane view cmds 0xd3, 0xd4,
0xd5 and 0xd6 do interfere also. maybe even 0xcf. all these cmds are described in
the command-library.
for a wild guess (by M) you could try and give a range 2000-2060 for a2 - a3 in 0xc5
(2000 -2060: when 2000 would be the begin of the inner part of the pit lane and the
length of the pit lane would be 60 at most)
0-Posted by Derek from 205.200.28.46:
Hi there,
While fiddling around with Suzuka I think I have found out what a8 of the oxc5 cmd
does.
When leaving turn 2 and continuing through the top of the dunlop curve, I wanted
to see the s/f straight, objects etc. After Addie set me on the right track, I managed
to get what I wanted. The only problem was when I went through the S curves, and
the car was going from left to right, as I went from left back to right the scenery
from the other side of the track (as defined by oxc5) would flash off for a split
second and then come back on as I went back to the right.
I inserted a value of 16384 in a8 and it stopped the problem (I arrived at this value
simply becouse that is what others have used). Now the scenery was fine no matter
which way the car was pointed.
So I think a8 has to do with the rotation of view (sorry if that doesn't make sense)
from the car.
Hope this helps in some way.
Thank,
Derek Hicks
Posted by Bob Culver from 63.21.201.228:
Yes. A8 is rotational value like used for the 0xaf A2 and A3 values.
Posted by addie from 194.191.82.13:
i’m afraid its not that easy. its not even easy to explain the problem :)
we all agree: with a8 the visibility of the “far-view”-section can be somehow set
up. most of the time some flashing goes away when increasing the value of a8. but
how does it work exactly ? is it an angle of visibility ? rotation of what ? both
sides left and right affected at the same time ? behind and in front ? where is 0
degree ? does a8=0 means 0 degrees ? 0 degrees of what ? does it matter whether you
look from the start of the “far-view”-window or from the end of it ?
you will agree with me, so far its not yet 100% predictable.
i made a base- and testtrack for future use and checking out things like that and
more. if anybody is interested in it, please dont hesitate to drop me a line ...
Posted by addie from 194.191.82.13:
i dont think so (if i understood the term correctly). it has nothing to do with distance.
this is set up with a2 and a3.
i'm pretty sure it has something to do with angles only.
maybe the circumference is divided into pieces which got enabled by switches ?
i did not have the time to go deeper into it so far ...
Posted by Bob Culver from 63.21.231.38:
OK, How about periferal angle?
Posted by addie from 194.191.82.13:
my best approach so far: imagine a line from your head (point of view in the game)
to the "far view"-section (i cant say to where exactly in the “far-view”-section).
this is zero degrees. now imagine you turn your head. i guess this is what bob called
periferal angle (?). 0, 90, 180 and 270 degrees, all +- about 20 degrees seem to
be visible all the time (e.g. at a8=0). with increasing the value of a8 you can "fill
up" the gaps, so at latest with a8= 16384 you could make a full circle. this
worked at least in my example. however you may want to check out several values for
getting the best result.
Posted by Bob Culver from 206.173.161.180:
Sounds like periferal angle is correct. I have a question though. When you state
that the A8=16384 makes a full circle, does that mean that it works behind the car?
Sort a view far distance behind? Or, would it mean complete periferal vision in front
from left to right, which would be 180 degrees?
0-Posted by µartijn from 145.94.124.79:
Hi!
I have seen many requests lately about object editing. Is there any interest in perhaps
a short tutorial about changing scales and so on?
Posted by Bob Culver from 206.173.161.177:
Yes! I currently do a lot of trial and error with objects. It would be extremely
helpful if you have any advice on texture rotation values as well.
Posted by µartijn from 145.94.124.79:
My advice on texture rotation on objects is as follow: It's not possible. End of
story. Sorry. It sucks, indeed, but you'd have to rotate the texture on the JAM instead.
BTW if you have a object-related question, you could try to send it to me so I know
what are the bottlenecks in object-editing, and to include perhaps a FAQ.
M.P.J.Keizer@sepa.tudelft.nl
Posted by Paul Hoad from 195.92.194.76:
If I could be of any help let me know!
Paul
Posted by Martijn from 145.94.124.79:
Yes, Paul, could you perhaps tell a little more about the orientation of textures?
Obviously you can somehow derive from an object the orientation of the textures,
as in the TE they are displayed correctly.
I remember John saying something once about it being dependent on the orientation
and order of the lines that form the plane? Could this be changed easily?
Posted by Paul_Hoad from 212.2.17.129:
If I draw it correctly it could be more by luck than by judgement
here is the code that draws the object
for(i=0;iver-points;i++)
{
int ap1 = ver-getPoint(i);
if (ap1 == -32768) {
ignoreNextTexCoord=TRUE;
continue;
}
int abap1 = abs(ap1);
if (abap1 = connections) continue;
int vidx = ap1 = 0 ? (VerticiesArray[abap1].pt1) : (VerticiesArray[abap1].pt2);
double dx1 = ((double)(ptArray[vidx]-x)*SC);
double dy1 = ((double)(ptArray[vidx]-y)*SC);
double dz1 = ((double)(ptArray[vidx]-z)*SC);
if (!ignoreNextTexCoord)
{
switch(cornerProcessed)
{
default:
case 0:glTexCoord2f(1.0f,0.0f);break;
case 1:glTexCoord2f(0.0f,0.0f);break;
case 2:
if (ver-points == 3)
{
glTexCoord2f(0.5f,1.0f);
}
else
{
glTexCoord2f(0.0f,1.0f);
}
break;
case 3:glTexCoord2f(1.0f,1.0f);break;
}
cornerProcessed++;
glVertex3d(dx1,dy1,dz1);
if (i0)
{
ver-cx += dx1;
ver-cy += dy1;
ver-cz += dz1;
ver-cx /= 2.0;
ver-cy /= 2.0;
ver-cz /= 2.0;
}
}
else
{
ignoreNextTexCoord=FALSE;
}
}
I'm not sure if you can read this but it might help alittle?
Paul
Posted by µartijn from 145.94.124.79:
Damn, I should have gotten an education....
Anyway, I'm not a programmer, so perhaps you could explain in plain English how you
determine the rotation of the texture on a plane?
Posted by Paul Hoad from 212.2.17.129:
I can only assume it down to which vertex you specify first
The polygon are defined by vertex pairs defining a direction from what I remember!
so say we have a square
A------B
| |
| |
C------D
it defines vertex pairs of
(1) AB
(2) BD
(3) DC
(4) CA
so it defines the vertexes as
1 2 3 4
to rotate a texture by 90 degrees I would have though
you specify
2 3 4 1
I don't remeber seeing any
commands to rotate the texture
only the number of repeats vertically and horizonatally
Paul
Posted by Martijn from 145.94.124.79:
This is exaclty what I was looking for!
Is it be possible to change the definition of the polygon in the way you describe?
I'm sure that if you change
1 2 3 4
into
2 3 4 1
that the texture will end up rotated, and a bunch of object editors would end up
very happy.
(BTW Paul, when you view the Tunnel Entrance-object of Monaco in the TE (and texture
it), the TE crashes)
(BTW so far 2 people showed interest in an object-tutorial, both named Bob! How do
you explain that!)
Posted by Paul Hoad from 212.2.17.129:
This would involve adding 3 scale values at the same time as add one single vertex
which
I suppose would be good but also would be eating up valuable space.
I belive the reason for the
scale/vertex/polygon approach was that Geoff could make a
building or bridge and it didn't much matter if it was
100% correct he could fit it to the track later and scale
it so that it was the correct
proportion.
Paul
Posted by Paul Hoad from 212.2.17.129:
Talking about rotation does anyone know if the
3,131 rotation flags work for
the textures.
do people use the object editor to edit objects or
the TE?
Paul
Posted by Paul_Hoad from 212.2.17.129:
We have all seen the following haven't we!
==========================
Internal Object Structure
The idea of this document is to disclose what we know so far about the structure
and the syntax of the internal objects within
gp2. The aim is to provide people with an understanding of the format so that they
may easily edit existing objects while
consolidating what I know so that I can approach towards a method of being able to
construct an objects from stratch.
How Complex?
Initially it was thought that the internal objects would not be very complicated
but as time has continued these objectsare found to be a highly complex command structure,
similar almost to the contruction of track...
Whats the main idea
Well internal objects in general contain the XYZ data need to draw the 3D objects,
they also contain references
to the textures that are needed to map to the XYZ data, but they can also contain
references to external objects
so we need to understand how an object is put together and all the possible syntax
of an object.
Internal File Structure.
Well you'd think that we would totally understand this by now but infact we don't
there is still a large part
that is very difficult to understand and even some parts we haven't even had time
to explore yet! but I'll
get to that stuff later on. So what is the structure of the file
Header
Scale Data
Point Data
Vertex Data
Texture Commands
Unknown Data
Well this is grossly simplified but for now this is all you need to know.
the aim here is to provide enough information to actually site down and write a tool
that will allow the creation of new objects for use within gp2. So to do that we
will need to have a complete understanding of each section.
Firstly I'm not going to describe the header yet becuase this is quite complicated
but lets get down to the nitty gritty with the XYZ data itself.
Geoff Crammond uses a number of tricks to minimize the number of 3D calucaltions
he needs to do to display the objects and as such the format of the file may not
seem that obvious but this is how it is. If your used to Car Editing or some simple
object editing then you'll understand what is going on but if not here is a quick
refresher.
Scale Data
The size of the object is contain within the scale data this is simple an array of
numbers
that can be used along any axis as a means of scaling the whole object. for example
I can describe a 3D cube (if s = 255) in terms of X,Y,Z polygons like this
// bottom
s,s,0
s,-s,0
-s,-s,0
-s,s,0
// top
s,s,255
s,-s,255
-s,-s,255
-s,s,255
but of course by changing s to a differnt value I can make a different size box
now you can see the power of using scale values...because if you want to
resize the box only one piece of data needs to change!
so the internal objects define a list of scale values this is just a simple list
(picture!)
Point Data
Next comes the point data and this is a little more complicated so it needs some
attention.
XYZ data is in form (Xid Yid Z Unk) Xid and Yid point to either data from Scale data
table or to
previous define X,Y
the Z value is always unique for each point but the X and Y don't have to be.
this means that you can define the bottom and the top of a box to use the
same X and Y meaning that if you want to increase the size of the box you
don't need to update every single point in the cube.
So how do I read the data?
well the XYZ data appears in two forms
a) 0x84 0x4 Z value
or
b) 0x8002 ?? Z value
a) means use a scale value and b means use a previously defined point
(for a more detailed view of this please look at the car editor section
Vertex List
The vertex list simple defines the interconnections between points
the key thing to remember is that vertex's have a direction and hence
run from one point to another.... (this will be important later, so remember this!)
Texture Commands
Ok upto now my other info sources on this have covered this topic very badly
well there is a good reason for this, Texture commands are at the cutting edge of
what I know and I'm finding new ones each day. So here's what I know.
Initially I though that the commands were defined by some 0x83 and 0x03 commands
but I now see this to be incorrect thanks to an accidental discovery by Michael "NRG"
and now this is fundamentally changing the way I look at the commands.
firstly you know how commands are in a single track section well this is exaclty
how
the texture commands are encoded into the texture section except the commands have
a variable number of arguments but I'll explain what I know.
firstly their are a number of different texture commands I'm not sure what all do
but most
define a polygon of some description with a few exceptions. The beginning of each
command
located by the existance of a command number i.e.
0 xx xx xx xx
1 xx xx xx xx
2 xx xx xx xx xx xx
3 xx xx xx xx xx
4 xx xx xx xx xx
5 xx xx xx xx xx
ok so we can see the data now lets have a look at what we can read from each command.
firstly lets define an average looking command as
number data1 data2 data3 data4 data5 .... dataN
well we know number now
data1 is appears is a command id signifiy a command type
there seems to be alot of these commands and I'll show these in some kind of table
later.....
depending on the command the rest of the data will be interpreted differently
but so far I've seen too main types of internal object.
a) A basic object like a stand,bridge or advert
b) A compound object of a nunber trees, bushes etc...
so in the case of (b) the command number is 0x80 (128) which is a coincidence because
this is the command number for objects within the track.
in the case of a) this number seems somewhat smaller generaly between 0x2(2) and
0x20 (32)
but the meaning of the different commands is not 100% understood. but it will be
:-)
so lets take an example texture command from say an advert (japan, IO 26 , advert)
the first command for this advert looks like this (in dec)
0 24 30 131 1 256 256 -1 2 3 -4 0
ok look horrible but your about to discover the full meaning of every item.
0 means the 1st Texture command of this object
24 is the command id (0x18)
30 is the texture id (an Olivetti sign in my version!)
131 (0x83) is actually the roatation of the bitmap (thanks NRG!) seems this is like
the (0xbc texture mapper)
in that the rotation is 128 + 3 other values for this command seem to be (0x3) but
I bet you could rotate but 90 degrees if you use something like 65 (just like 0xbc)
Michael Wrote
131 (8x16+3) - normal
192 (12x16) - normal
208 (13x16) - mirror
224 (14x16) - mirror
240 (15x16) - mirror
256 (16x16) -up side down
This value also denotes if there is to be any further argument following this (i.e.
flags)
there fore a simple test of rotation being 0x80 means there will be more data before
the
verticies
1 seems to be something to do with the number of arguments that follow prior to the
vertex list
(values for this are 0x1 0x10 and 0x11 not seen any more yet!)
0x1 means read one arg
0x11 means read two args
0x10 means read no args
this can also be
0x3 means read three args
0x4 means read one args
0x5 means read one args
this seems to be alot of other values too... more on this later
256 is the Horizontal Repeat (/256) meaning take this number divide by 256 and this
is the number of time this command repeats (you may find on some objects, jerez bridge!)
that this number is less than 256 this might signify the amount of a single bitmap
you would
like to see but this is not tested yet!
256 is the Vertical Repeat (/256) same as aboe
then comes the vertex list
(-1 2 3 -4)
which is not always 4 items infact I've seen it with as little as 3 and as many as
8.
ok so how do I read this then......
I told you to remember about vertex direction this is were it comes in importantly
this polygon is defined by
vertex's 1 2 3 4 but 1 and 4 run in the opposite direction to the way they were defined...
ok so lets look at how they were defined...
number = from_point_id - to_point_id
1 = 0 - 1
2 = 0 - 2
3 = 2 - 3
4 = 1 - 3
so the -1 means 1 - 0
and -4 means 3 - 1
so the vertex list read
-1 2 3 -4 which translates to
1 - 0 - 2 - 3 - 1
1 --------------------------0
| |
| |
3---------------------------2
an objvious rectangular strucure!
now something very important here is that this defines the
polygon in a clockwize direction this is important because
the direction of the polygon defines which way the polygon
is facing and changing the direction means gp2 will backface
cull it and remove the polygon from view if it thinks its facing the
wrong way!
this is why when people edit the vertex list sometimes they have
problems with the polygons they were editing disappearing.
Some people have noticed the -32768 in the vertex list this seem
to mean ignore the next point as a texture corner!
ok so now you know all about Polygon Texture commands
and you can go into the world happily editing to your hearts content!
but what about the other commands
well the format seems to be similar with the exception of a few of
the commands
Compound Objects
I said early that some of the commands were 0x80 type commands
well I've only just discovered these and they seem to be of the
format
arg1 = number
arg2 = cmd (0x80)
arg3 = pt array index
arg4 = 255
arg5 = jam id
in this case the only thing that is important is the pt array index
and the jam id here the pt array index means put the object on this
point and the jam id index is much like the id2 value for ID5 type objects
in that if you add 255 to the id you'll get a jam id (usually for a tree!)
this seems to be the main use for the 0x80 command. but this could be
a very power full command for placing objects close together on both
sides of the road which is what happens with some of the tree objects
at germany because of the (you can't have two objects at the same distance
rule!)
I noticed that 0x86 also exsits in Building with bridge at Monaco
this has and
arg6 = offset locator of track object description
Other Object Observations
Object Command types
0x80 (128) is use an object
0x86 is use an object but this time seems to take another argument which is equals
to the offset locators of the TrackObjectDescription table
0x10 (16) is possiblly a transparent object
others seen
0x0a (10)
0x0b (11)
0x0c (12)
0x10 (16)
0x11 (17)
0x12 (18)
0x13 (13)
0x14 (14)
0x15 (21)
0x16 (22)
0x17 (23)
0x18 (24)
0x19 (25)
0x1a (26)
0x1b (27)
0x1c (28)
0x1d (29)
0x1e (30)
0x1f (31)
Some exist less than thse
0x3
0x2
but they seem to have less arguments
Posted by µartijn from 145.94.124.79:
I'll be honest, Paul, I didn't know.
What a question about an object tutorial can spawn...
I have always used the trackeditor to edit objects, and I haven't done much more
than changing scales, and changing the references to scales of a point. And textures
ofcourse. That's not a lot, but I have a feeling no-one does a lot more than that
(please tell me if you do, and please write a tutorial about it!)
I didn't know about the "hidden" 131 value in a texture command. It isn't
editable in the TE, right? Could it be made editable? Sounds like something enjoyable.
Anyway, I just tried to rotate a texture (by 90degs) by changing vertex-connections,
from
(poly: -17,18,19,-14)
17: 1-2
18: 1-5
19: 5-6
14: 2-6
to
17: 5-1
18: 5-6
19: 6-2
14: 1-2
and that worked OK for the polygon I wanted to change, but ofcourse it messed up
the connecting polygons that use the same lines.
As far as I know, the defining lines of the polygons aren't editable either, are
they? Could they be?
It would be much easier to just change the polygon to (18,19,-14,-17) (am I correct
here?) and not mess up the rest of the object.
0-Posted by addie from 194.191.82.13:
hello
i had a closer look at the regular view-distance cmds 0x81, 0x82, 0xbe and 0xbf.
some is old news but some is really news i guess:
- view-distance “follows” the track-layout. so the image of a view distance radius
is wrong and misleading. if a certain position on the track is within the view-distance
everything connected to the track at this position is visible also, whatever distance
to the right or left it has. on the other hand if we have a crossing (like e.g. Suzuka)
the “other part” of the track is not visible if its too far away according to the
view-distance along the track (as its the case with Suzuka). thats where we need
0xc5/c6 ...
- default view-distance is about 60; smaller values in the cmds or the inexistance
of those cmds do not affect the default value. within the default view-distance all
locations show up. this means the view-distance is never smaller than the default
value. the valid range of the view-distance in all cmds is 60-255. if the value is
greater than 255 it starts over at 0 (so e.g. 280 actually gives about 25)
- 0x81 and 0x82 do ONLY extend view-distance of road and ribbons !
so if you e.g. set a view distance of say 100, you have all locations until 60, and
just road and ribbons for the rest of the distance.
- 0xbe and 0xbf extend the other locations also, according to the setting of their
a2;
however road and ribbons are always extended (just like with 0x81/0x82).
- a2 of 0xbe and 0xbf is another new location code type E !
the new location code type E:
1: right verge
2: left verge
4: right fence
8: left fence
16: right bank
32: left bank
so if you want to see all locations, you set a2=63
it looks to me, as 0x81 and 0x82 are completely unnecessary if you have 0xbe and/or
0xbf !?
please anybody confirm !
however if you insert them paired up 0x81/0xbe and/or 0x82/0xbf as can be seen in
all original-tracks, watch out for how the arguments work: the view-distance is given
by 0x81/0x82, whatever is set at the other cmds 0xbe/0xbf. and the locations are
given by 0xbe/0xbf ...
i hope its useful information
addie
Posted by Paul Hoad from 212.2.17.129:
I think this is probably one of the areas where GP1 tracks got converted to GP2 tracks
and Geoff had to make new commands to do extra stuff but it would be interesting
to see if which tracks contain
the 0x81 0x82 commands?
are they only the tracks that might have come from F1GP
Paul
Posted by addie from 194.191.82.13:
i checked this in particular. they are also in the "new" tracks f1ct02
and f1ct14 ...
i'd suggest to only use 0xbe/0xbf unless there rises some problem (but then please
contact me!).
Posted by Bob Culver from 63.21.201.228:
Wouldn't you still need the 0x81 to define the view distance for the road and the
ribbons?
Posted by addie from 194.191.82.13:
no.
road and ribbons are there also with 0xbe/bf as far as i saw.
with 0xbe/bf road and ribbons are there always and the rest can be set up with a2.
if anybody has different experience please contact me !
0-Posted by David Richards from 202.12.71.11:
I have a strange distortion on the latest track - thin stripes across the screen
like venetian blinds
Posted by addie from 194.191.82.13:
is it a long track ? when you come near the length limit sometimes things like this
happen.
you may also try to load it in other slots.
Posted by addie from 194.191.82.13:
the source for the thin stripes across the screen was: the pit-exit and/or -entry
was too close to the s/f line. pit-entry and pit-exit have to have a certain minimum
distance from the s/f-line. this minimum distance is about 5-10 length units and
depends on the slot where the track is plugged in. with pit-entry and -exit i mean
the position where the “two worlds” were connected by the cmd-triples (0xa1, 0xa2,
0x9f) resp. (0xa3, 0xa4, 0xa0)
0-Posted by David Wortley from 212.159.3.215:
Could the fact that I have a AMD be the reason for TE to keep crashing on me?
Posted by Paul Hoad from 195.92.194.78:
No I have an AMD
end of list