Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - TSJ

Pages: 1 [2] 3 4 ... 7
16
Development / Re: contents of garage
« on: January 06, 2015, 01:47:27 pm »
@TSJ I am also willing to spend my free time on some SR3 coding if you are also interested. Contact me through IRC, GTalk/Hangouts (my e-mail address is on my profile or drop me a PM if you can't see it). I also have Skype, Facebook, etc. if you're interested. This way we could have a short discussion session about plans and such. :-)

Sounds very cool :)

Atm we don't have anything really usefull,
I have limited spare time due to cats, wife, a child and a very long drive to and from work :)

My status is this...

I was able to compile the code from the old alpha in visual c++ 2008 and
I made a very small experiment with making a 3ds model "drive" in to the garage and
last I spend time on the project I had begun making some skeleton classes for representation of the car and its various parts.

:)

My local time zone is GMT+1

17
Development / Re: contents of garage
« on: January 02, 2015, 12:40:44 pm »
Yes.

Are any of the other coders still active or whats their status?

So basically the BNF is programing language as Strunk and White rules (Grammar, punctuation and spelling) are to the English language?

Yes.


18
Suggestions / cannonball run
« on: January 02, 2015, 12:21:15 pm »
According to http://en.m.wikipedia.org/wiki/Cannonball_Baker_Sea-To-Shining-Sea_Memorial_Trophy_Dash

the first competitive cannonball run was hekd in 1972.

So it could be a real and accurate "thing" to have in a sr3 game.

19
Development / Re: contents of garage
« on: January 01, 2015, 03:17:20 am »
Happy new year to everybody.

Hopefully I will gain some more practical knowhow about 3d game creation this year. I do have a degree but I have always been tempted by and chosen other types of  IT jobs such as embedded software development.

20
Development / Re: contents of garage
« on: December 31, 2014, 06:29:25 am »
Well altering the mapping on the fly would be something tha would be done from inside the game and would require some sort of system to determine what textures to use.

I am not sure what the point woould be, I used the part.mat files to create various versions of existing parts in the old sr3 alpha... such as for example variations of the kelsey hayes wire wheel in various colors and with various decorations (whitewall, text, etc)

21
Development / Re: contents of garage
« on: December 29, 2014, 01:52:04 pm »
I am not sure if one way is better than the other ... I guess from a modelers point of view its best to include mapping in the 3d file like with irrlicht and various formats like 3ds. But I think the 3ds max exporter generated a special data file automatically based on model data from 3ds max? But what I remember is that it was possible to alter texture mapping by changing the data files but without altering or opening the file that contained the model itself.

if I remember correctly the alpha version 0.4.4.1 used xml files to hold texture info about the models
while the aux files only contained model data... I will double check this and post my findings.

GOOD NEWS! I have changed the code (to remove compile errors) in the OLD alpha 0.4.4.1 so that it now COMPILES with the FREE VERSION of visual c++ 2008 EXPRESS... AND. .. THE ....RESULTING.... SR3 EXE ... IT ... RUNS ...

It was mainly a question of some of the commands being depricated or some shorthand coding that Visual Studio 2008 did not accept :) :) :)

Also... it turns out that the project is well structured now that I figured out what file to open in the IDE (D'OH)  :) I think I MIGHT be able....

to make some more changes to the source of the old / current ALPHA 0.4.4.1 :) :) :) :)

I am currently trying to fix the bug with the wheels placed at a clockwise rotation when the car is on the track

A little CS theory...

every language is ruled by a BNF.  Each compiler must  comply to that BNF in order to compile code

A BNF is the formal mathematical definition (a set of rules) of the syntax and semantics of a programming language

So every c++ compiler follows the same BNF more or less. But some are less strict than others regarding semantic rules

The previous compiler tolerated some stuff that visual c++ 2008 does not but the changes still allows to old compiler to compile the project because they must both use the same basic BNF in order to be c++ compilers

I had to fix the following...

variable scopes
missing typecasts
a missing header file (I found a free implementation of that file on google)

One of my previous jobs was teaching computer science at a local university college.

----

just looked at the old alpha... each car has a car.aux and a car.mat

the mat file is an xml like file tha contains info about texture mapping... here is the car.mat from my old 32 ford model:

NotPaint {
   Pass1 {
      Texture CAR01.TGA
   }
}

Window {
   Pass1 {
      RGB 0.900027, 0.900027, 0.900027
      Alpha 0.500000
      Blend b_alpha
   }
}

Window2 {
   Pass1 {
      RGB 0.070588, 0.070588, 0.070588
      Alpha 0.500000
      Blend b_alpha
   }
}

CarMaterial {
Pass1 {
TcGen tc_sphere
Texture envmap.bmp
}

Pass2 {

RGB 1,0,0

Alpha 0.75

Blend b_alpha

backcull false

}

}

Dials {
   Pass1 {
      Texture Dash00.tga
   }
}

Fabric_Tan_Carpet {
   Pass1 {
      Texture seat.tga
   }
}

Grey {
   Pass1 {
      Texture grey.tga
   }
}

ShinyMetal {
   Pass1 {
      TcGen tc_sphere
      Texture chrome.bmp
   }
   Pass2 {
      Texture grey.bmp
      Alpha 0.75
      Blend b_alpha
   }
}

keyhead {
   Pass1 {
      RGB 0.000000, 0.435294, 0.192157
   }
}

keyhanger {
   Pass1 {
      RGB 0.266667, 0.192157, 0.545098
   }
}

pedal {
   Pass1 {
      RGB 0.131373, 0.052941, 0.162745
   }
}

steeringwh {
   Pass1 {
      RGB 0.545098, 0.266667, 0.192157
   }
}

Black {
   Pass1 {
      Texture BLACK.TGA
   }
}

Mirror {
Pass1 {
TcGen tc_sphere
Texture envmap.bmp
}

Pass2 {
RGB 0.533333,0.533333,0.533333
Alpha 0.75
Blend b_alpha
backcull false
}
}

Bulb {
   Pass1 {
      RGB 0.770588, 0.000588, 0.000588
   }
}

22
Development / Re: contents of garage
« on: December 29, 2014, 03:39:25 am »
I think it should work on linux if GCC for linux will compile it. I am not using any OS specific stuff.

The 32 and the wheels still looks like hell but it is because I have not yet ben putting textures on them
( as you might remember, in the old alpha the textures were not mapped in the aux file,
  but in a seperate file :) )

I will make another attempt at getting the old SR3 code to compile though, since there has already been put a lot of work in the previous alpha code.


23
Development / Re: contents of garage
« on: December 28, 2014, 02:38:00 pm »
youtube video of start animation

https://www.youtube.com/watch?v=zLfGanjfwl4&feature=youtu.be

now with correct wheel rotations

24
Development / Re: contents of garage
« on: December 24, 2014, 02:58:30 am »
Sounds good.

I am tempted to try and see if I can use quake 2 models as "drivers" for the cars :)

I think that we will need to create a game that is even closer to the look and feel of sr1 and sr2 than the previous sr3 versions were.... (like car entering garage, drivers for the cars, popping the hood to work on the engine etc)

I have wheel animation at this point but the wheels spin in the wrong diirection no matter if I manipulate the X, Y or Z axis so I need to figure out why that is.

25
Development / Re: contents of garage
« on: December 23, 2014, 07:51:25 am »
Irrlicht does support bones animation.  Both animation that is part of the model and custom is supported.

I dont have experience with bones animation but it should be possible to make it work.

I think it could make sense to use both types I guess if we
can actually call dummy objects for an animation type.

but we can use both. Some stuff might work best one way and other stuff might work better another way

I mainly think of charecter animation when talking about bones.

with wheel I talk about rims and tires

I currently have an animation where the car enters the garage upon start of the "game"
It still lacks wheel animation though.

26
Development / Re: contents of garage
« on: December 21, 2014, 08:03:15 am »
I wonder if Hellmark has the source and or more information on the old AUX format.

Also i don't mean changing out models, i mean how the game handles them. sort of like. I mean like weather or not we uses bones for wheel and part locations or just objects names etc etc, would such change require vast rewriting of code?

I found the source code for version 0.4.4.1 ( streetrod3-src_0.4.4.1 ) on an old hdd backup.

I will try to see if it compiles in visual c++ 2008 express

If not then I might still be able to use lots of stuff like the 3ds format code (since it is also coded in c++)

I think that we would need some re-coding if we decided to switch from dummy objects to bones... but the more modular the code is, the easier it is to change stuff.

I think I might be able to make the car driving into the garage animation during the holidays...

I have been improving the test wheel slightly ( I decided not to use the turbine wheel for testing)

I now have the car in the garage with 4 "custom" wheels attached.

27
Development / Re: contents of garage
« on: December 20, 2014, 04:50:18 am »
Seems to be limitations that come from the 3d file formats. .. I will attempt to use an xml file to store object names... that way everything can still be contained in a single 3ds file if needed.

It seems the aux format of the prev sr3 was very clever made... both protection of art as well as objects with names were build-in

28
Development / Re: contents of garage
« on: December 18, 2014, 06:11:02 am »
According to http://irrlicht.sourceforge.net/forum//viewtopic.php?f=4&t=16632&hilit=3ds+multiple+objects

then it IS possible to seperate multiple meshes/objects within a 3ds file, but it must be done using index instead of names...

I will experiment with this...

Perhaps if object names are loaded sequentially according to name,

then we can atleast know what is what if we have a fixed set of dummy objects/meshes that all start with Z

(assuming none of the additional objects/meshes use names that begin with a Z)

This unfortunatly disallows adding additional car specific named dummy objects, that is, all cars must have the same maximum set of dummy objects since the index of each dummy object is then hard coded,

A workaround for this issue could be a combination model (that is both dummy objects within main 3ds file as well as seperate objects controlled by configuration file) where additional non standard car parts are placed in seperate 3ds files along with a location, and behaviour, configuration for each car that supports the use of that particular part...

To answer your question from earlier...

that might be an issue. for what standards we do define for the 3d models? the old SR3 standard are quite outdated. i wonder if can ad and change them as we go with out significant reprogramming being needed?


Yes, we should be able to change the models without too much hassle... Irrlicht should not care too much about what poly count a model has.

So this should pretty much allow for drop in replacement models that are much more detailed and much more realistic.

29
Development / Re: contents of garage
« on: December 16, 2014, 04:59:36 am »
what I mean by object (as defined by zmodeler 1 I think?), is collections of meshes in the 3ds file..

for example I think of the front left wheel dummy as an object within the 3ds file...

What I want to achieve for now, is to be able to (with irrlicht) to

a) load a single 3ds file and

b)  then afterwards select for example the front left wheel dummy object

c) and then hide it,

d)  then I want to load another 3ds file that contains a wheel, lets call it testwheel.3ds

e) and then use the coordinates of the wheel dummy to place the wheel from testwheel.3ds

f) and then use the local axis of testwheel.3ds to "spin" the wheel while moving the car

spinning and rotating stuff like wheels, steering wheel, running gear parts etc, could be done simple by rotating them along their own local axis

So either I need to find out how to do this in irrlicht or else I will need to place all parts of a car in seperate 3ds files and then use a setup file instead of dummy objects to assemble the various meshes from the various 3ds files in to a car

the setup file would then need to contains something like this:

body, x, y, z position
steering wheel, x, y, z position
front left wheel, x, y, z position
front right wheel, x, y, z position
rear left wheel, x, y, z position
rear right wheel, x, y, z position
front left headlight, x, y, z position
front right headlight, x, y, z position
rear left taillight, x, y, z position
rear right taillight, x, y, z position
engineblock, x, y, z position
manifold, x, y, z position
enginefan, x, y, z position
etc etc

IF Irrlicht supports multiple objects within a single 3ds file, then most stuff could be handling using dummys within the cars 3ds file...

Anything that can be replaced or moved in some way or have some other function like lights would need dummy objects

The other option to have a bunch of 3ds files would also work and might make it easier to be able to replace body parts like doors etc... I was thinking that it could be kind of cool if it was possible to for example replace the left and right rear fenders with other types... like one set of fenders could have "wings" and another set could have no wings... stuff like that (like in Gearhead Garage )

30
Development / Re: contents of garage
« on: December 15, 2014, 02:34:54 am »
Interesting point. In regards to 3d models, to begin with we can still use some of the old low poly models I think.

I did hit a roadblock though. It seems its all objects or nothing per 3ds file with iirlicht. I hope I find a workaround.

But then again there is also the ogre 3d engine

Pages: 1 [2] 3 4 ... 7