Quantcast

Jump to content

» «
Photo

Open-source GTA3 engine?

41 replies to this topic
lpgunit
  • lpgunit

    It's L, as in Lpgunit, not I.

  • Feroci Racing
  • Joined: 24 May 2008
  • Philippines

#1

Posted 15 December 2009 - 03:36 AM

With all the info we gathered and reverse-engineered from the III-era games, is it possible, or at least feasible, to write an open implementation of the III/VC/SA engine or binaries? I've heard of at least one effort done involving Vice City and an engine who's name I forgot, but are there any ongoing efforts to write a free clone? It might displace Alex Blade and Seeman's ASIs as well as numerous EXE hooks and patches (since we can integrate those in the main binary itself), but are there any ongoing efforts on this?

H13N.H3N
  • H13N.H3N

    Lands with a *Clunk*

  • Members
  • Joined: 20 Jul 2007

#2

Posted 15 December 2009 - 02:16 PM

QUOTE (lpgunit @ Dec 14 2009, 21:36)
With all the info we gathered and reverse-engineered from the III-era games, is it possible, or at least feasible, to write an open implementation of the III/VC/SA engine or binaries? I've heard of at least one effort done involving Vice City and an engine who's name I forgot, but are there any ongoing efforts to write a free clone? It might displace Alex Blade and Seeman's ASIs as well as numerous EXE hooks and patches (since we can integrate those in the main binary itself), but are there any ongoing efforts on this?

man, that would be fncking great, i work on Linux and an Open Source GTA 3D engine would be just awesome for make a binary interpreter for the game, if such thing exist mos provably that is uploaded or registered in Source Forge. Now, i don't really think nor i hope this can be possible because at least with existing titles as their source is closed, modding is possible due reverse-enginering and hacking the exe, alternatively with ASI,DLL or Cleo files but you can always send a mail to R* asking if they can have in it it's wish list an OpenSource release, if they (R*, R* North, R*Leads*,TakeTwo, N-Vidia Software) tolerate a GTA community modding that destroy their game is because they are getting money for the game anyway, what you make with your game in your PC is more like your problem, this while you don't re-distribute the game or stole any component for own profit.

lpgunit
  • lpgunit

    It's L, as in Lpgunit, not I.

  • Feroci Racing
  • Joined: 24 May 2008
  • Philippines

#3

Posted 19 December 2009 - 01:29 PM

Sorry for the bump, but yeah, although they did it with the Elder Scrolls engine as well as Medal of Honor: Allied Assault, citing modding issues as a motivation for the project.

NTAuthority
  • NTAuthority

    member_title

  • The Yardies
  • Joined: 09 Sep 2008
  • European-Union

#4

Posted 19 December 2009 - 02:12 PM

Sadly most of the interest in GTA's internals seems to be dead, and I can't think of anyone left who would be qualified to even rewrite GTA3 in a compatible fashion... there are too many unknown data formats, and likely a lot of other problems.

lpgunit
  • lpgunit

    It's L, as in Lpgunit, not I.

  • Feroci Racing
  • Joined: 24 May 2008
  • Philippines

#5

Posted 20 December 2009 - 12:50 PM

QUOTE (NTAuthority @ Dec 19 2009, 14:12)
Sadly most of the interest in GTA's internals seems to be dead, and I can't think of anyone left who would be qualified to even rewrite GTA3 in a compatible fashion... there are too many unknown data formats, and likely a lot of other problems.

I guess so, since there are a lot of kinks to sort out in the engine especially when making a TC.

H13N.H3N
  • H13N.H3N

    Lands with a *Clunk*

  • Members
  • Joined: 20 Jul 2007

#6

Posted 20 December 2009 - 06:47 PM

QUOTE (NTAuthority @ Dec 19 2009, 08:12)
Sadly most of the interest in GTA's internals seems to be dead, and I can't think of anyone left who would be qualified to even rewrite GTA3 in a compatible fashion... there are too many unknown data formats, and likely a lot of other problems.

wouldn't be too hard for the modding community because smartest people in coding already have open the engine and saw how is made, i would say that the hardest part is making one open source engine (even if made by the community) recognized and even legal under GPL license 3.0 by Rockstart & Friends

Waltzing Mouse
  • Waltzing Mouse

    Punk-ass Bitch

  • Members
  • Joined: 27 May 2008

#7

Posted 22 December 2009 - 06:33 PM

Surely if it was based around the GTA III engine, R* wouldn't mind? I mean, they have more important things on their mind, like GTA V. And besides, they're using the GTA IV engine now.

It would surely be good if the engine had no limits - like the SA Limit Adjuster on steroids - removing all limits from the .EXE, only needing to edit a .DAT file to change things or something. That would make it easy to mod, even for beginners.

H13N.H3N
  • H13N.H3N

    Lands with a *Clunk*

  • Members
  • Joined: 20 Jul 2007

#8

Posted 22 December 2009 - 09:44 PM Edited by H13N.H3N, 22 December 2009 - 09:59 PM.

QUOTE (Waltzing Mouse @ Dec 22 2009, 12:33)
Surely if it was based around the GTA III engine,  R* wouldn't mind? I mean, they have more important things on their mind, like GTA V. And besides, they're using the GTA IV engine now.

It would surely be good if the engine had no limits - like the SA Limit Adjuster on steroids - removing all limits from the .EXE, only needing to edit a .DAT file to change things or something. That would make it easy to mod, even for beginners.

if you ask me, i'm sure they actually will mind and a lot, because an Open Source Engine of GTA would make more or less unnecessary buying their past games or at this level, the IV version, as many of us know modeling and can reproduce vehicles with the same or better quality than R*'s graphic designers did (still an impressive work if you ask me, they had to make low-polygon version of real life vehicles to fit PC specifications and still looking very good taking as example GTA III for it's time). want it or not even GTA, GTA II and GTAIII are still requested by people not for mention VC and SA. Also i was thinking how this can be conceived, because at the end is not just simple as it could seem, for example, GTA III, GTA VC and GTA SA relies on DirectX libraries and functions, DirectX is trademark by Microsoft which means is a proprietary software, so in first instance the new engine would need to be build for use OpenGL 3D engine (as good as DirectX btw), also mp3 support would have to be handled by third party encoders like LAME, this because mp3 is also a proprietary format, so some audio files would be also in .ogg extensions (open sound format) that covers more or less some aspect, but for example, R* would need also to re-write entirely the format of their models,textures,animations,map files and so, this because all of them are closed from source, nor even supposed to be accessed by any program in theory, so.. this would take what a new release of GTA could be, and well.. they wouldn't have any profit indeed, and plus knowing the way they think, they would think on that as 'enhancing the piracy market' which is completely false as with any other Open Source software.

Edit:

I looked at SourceForge.net just to see what i would find there, some of those ideas are barely good but far to being well designed, there are some tools but nothing what you can call an attempt for a complete GTA Open Source Engine, though not difficult to start one but would surely need lot of plans and organization

ghost of delete key
  • ghost of delete key

    ಠ_ಠ ... otter ...

  • The Connection
  • Joined: 27 Dec 2003

#9

Posted 17 January 2010 - 02:02 PM

QUOTE (NTAuthority @ Dec 19 2009, 09:12)
Sadly most of the interest in GTA's internals seems to be dead, and I can't think of anyone left who would be qualified to even rewrite GTA3 in a compatible fashion... there are too many unknown data formats, and likely a lot of other problems.

No, it's not dead, just hibernating. ph34r.gif

I'm currently mapping the function tree of the VC exe (which explains why I'm back browsing these boards. tounge.gif ) for something like this. Dunno why, but I've had a resurgence of interest in hacking VC.


True, it would be one HELL of a project, and would require a superior level of effort and dedication. Just look back at what it took to do Myriad, and it technically was never really finished. More like perpetual beta.
There is, however, no shortage of talent in GTAF.

@ H13N.H3N:
We've gotten around the copyright/piracy issues in the past.

An open-source engine would necessarily require the possession of a legitimate copy of the game in order to install and use it; this is not to difficult, and can be implemented in a number of ways.

Of course, for our purposes, there would really be no other requirement to use the models or other resources, all we'd be left with is R* canon. The concept and original storyline will always be theirs, and therefore even a completely scratch project bearing the GTA name would be a derivative work, and be theirs as well. wink.gif

I and another member have been toying with the idea of a new scratch project with a new storyline, and this is basically our discussion at this point.

@NT Authority:
It may be a bit of a feat, as a number of us have disappearerd, but many of the pioneers of decoding the game are still around.
The boards here and some off-site pages contain the sum total of our discoveries and invention, but sadly this is quite disorganized.
This would likely be the first step in such a venture: get it all in one solid lump first.

Shifty41s_beerhatsmilie2.gif

_Rob_
  • _Rob_

    Game Dev, Graphics Artist

  • Members
  • Joined: 24 Sep 2006
  • None

#10

Posted 17 January 2010 - 02:51 PM

This sounds very interesting indeed, would it require reverse engineering of the entire coding or more like a new engine emulating every tiny detail that makes the games truly Grand Theft Auto. I am very interested in these kind of projects and I'm sure if you perhaps talked to tank or another Admin about creating a new sub-forum dedicated to this project it would help drumming up support etc, and you might be surprised at how many people would be able and willing to help.

DexX
  • DexX

    Black Hat

  • Feroci Racing
  • Joined: 16 May 2002

#11

Posted 18 January 2010 - 01:39 AM

QUOTE
True, it would be one HELL of a project, and would require a superior level of effort and dedication. Just look back at what it took to do Myriad, and it technically was never really finished.

This depends on the project scope, and stated objectives. For myriad, the bulk of the work was creating art - map objects, textures, new vehicles, peds, etc. A quick glance at the credits of any gta game will reveal a massive art team, with significantly fewer programmers. If all the existing assets were reused, the team requirements would be very different than Myriads. In laymans terms, if we re-use all the models and textures, then only the exe needs to be "replaced" - we'd need programmers more than anything. That is, assuming the existing files are parsed directly, and not converted to a format native to the newer engine.

QUOTE
This sounds very interesting indeed, would it require reverse engineering of the entire coding or more like a new engine emulating every tiny detail that makes the games truly Grand Theft Auto.

Reverse engineering would provide useful insight into how R* tied together all the game data, but in the end it would be up to the programmers to re-implement the logic that drives the games.

QUOTE
Sadly most of the interest in GTA's internals seems to be dead, and I can't think of anyone left who would be qualified to even rewrite GTA3 in a compatible fashion... there are too many unknown data formats, and likely a lot of other problems.

..which formats are still unknown? I swear i've seen a editor or viewer of some sort for virtually any file or file type in use by the gta3-era games. Certainly the bulk of the important stuff is known (it helps that most of the non-art files are text based).

lpgunit
  • lpgunit

    It's L, as in Lpgunit, not I.

  • Feroci Racing
  • Joined: 24 May 2008
  • Philippines

#12

Posted 18 January 2010 - 05:39 AM

I also thought of the possibility for an open III engine partly because of ReactOS, which is a project for an open, binary-compatible Windows alternative. They did their thing by disassembling Windows XP, with one team cracking it and publishes the code as documentation, and the other implementing their own version of the code, to reduce the risk of copy-pasta and further legal ramifications.

ghost of delete key
  • ghost of delete key

    ಠ_ಠ ... otter ...

  • The Connection
  • Joined: 27 Dec 2003

#13

Posted 18 January 2010 - 11:39 AM

QUOTE (bammargera @ Jan 17 2010, 09:51)
... I'm sure if you perhaps talked to tank or another Admin about creating a new sub-forum dedicated to this project it would help drumming up support etc, and you might be surprised at how many people would be able and willing to help.

Actually, it happens the other way around. If something like this were to take off and gain a groundswell, then it might become officially hosted with its own subforum.

@ Dexx:

Good points, all.

It sucks hard that:
1) I can't run IV on my crappy box, and I don't have a CD key anyway,
and
2) R* decided to fnck everything up by making a massive ball of SecuRom sh!t to tie single-player and online play into a single package.

... because I'm dying to get hacking on the IV package. As you pointed out, most of the III generation has been exposed, there's little ground to tread there.

My view? I would love to see a revisitation of Vice and San Andreas with nicer GFX and ragdoll physics.
It just makes sense, nahmeen? wink.gif

Slightly off topic, I wish R* would have the sense to offer "heavy" and "light" package options...
If you aren't interested in drinking from the online gaming well, you could simply install a single-player standalone without having to connect and activate the game and do that whole dog-and-pony show.
That really burns me up. You should be able to install your game like before without keys.
Paul.dll can blow me. angry.gif I investigated whacking the protection in order to do a no-online/no-activation mod, it turns out that paul.dll is a polymorphic AIDS virus of a frontend, and compressed. No busting this one with my tools. confused.gif

And thanks again, Dexx, for activating my hacking gene way back when...
inlove.gif

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci Racing
  • Joined: 24 Dec 2007
  • None

#14

Posted 31 January 2010 - 08:44 PM

/me goes to learn C++


I'll tell you when I'm done, eh? xD

ghost of delete key
  • ghost of delete key

    ಠ_ಠ ... otter ...

  • The Connection
  • Joined: 27 Dec 2003

#15

Posted 01 February 2010 - 10:14 AM

QUOTE (Deji @ Jan 31 2010, 15:44)
/me goes to learn C++


I'll tell you when I'm done, eh? xD

You don't use C++?!

What do you use then, Delphi?
If so, you and me need to talk... ph34r.gif


more on-topic-


One Word:

IRRLICHT.

It's a badass little engine, and I have some GTA classes that load models and textures from GTA.

It's very incomplete though, an abandoned project from the Irrlicht forums.

It shows promise though.

/me goes to learn C++ too (more feverishly than I have been confused.gif )

lpgunit
  • lpgunit

    It's L, as in Lpgunit, not I.

  • Feroci Racing
  • Joined: 24 May 2008
  • Philippines

#16

Posted 04 February 2010 - 12:55 AM

QUOTE (ghost of delete key @ Feb 1 2010, 10:14)
One Word:

IRRLICHT.

It's a badass little engine, and I have some GTA classes that load models and textures from GTA.

It's very incomplete though, an abandoned project from the Irrlicht forums.

It shows promise though.

/me goes to learn C++ too (more feverishly than I have been confused.gif )

Maybe if we could reimplement that thing, although I mostly insist on a purist approach, much like a Duke Nukem 3D source port that tries to be as faithful to the original.

But then again, anything that could replicate III's functions in a convenient and open way can do.

If anyone is willing to start this project, then we need a manifesto and some stuff to go along with it, like the Debian manifesto thing Ian Murdock wrote back in '94.

coin-god
  • coin-god

    High Roller

  • $outh $ide Hoodz
  • Joined: 18 Mar 2007

#17

Posted 04 February 2010 - 01:04 AM

I dont think R* would give us the source code. They dont even help in modding.

Anyways, isn't it possible to get a "copy" of RenderWare? It shouldn't be free, but is it buyable?

I know it would not be the same, the GTA source is heavy modified, but it may help a bit.

DexX
  • DexX

    Black Hat

  • Feroci Racing
  • Joined: 16 May 2002

#18

Posted 04 February 2010 - 01:50 AM

QUOTE (goin-god @ Feb 3 2010, 18:04)
I dont think R* would give us the source code. They dont even help in modding.

Anyways, isn't it possible to get a "copy" of RenderWare? It shouldn't be free, but is it buyable?

I know it would not be the same, the GTA source is heavy modified, but it may help a bit.

R* only used the Graphics portion of Renderware (Renderware Graphics - there's also physics, audio, and some others). According to wikipedia Rw was absorbed into EA's internal tech and is no longer available for purchase. There's various versions of the RWG sdk floating around as torrents or somesuch, the most common being version 3.7, but i wouldn't recommend trying to build a project around them.

If there was a project started that would re-use the existing models and textures (the "Renderware" files), i would suggest converting them to the model/texture format used by the newer engine.

QUOTE
If anyone is willing to start this project, then we need a manifesto and some stuff to go along with it, like the Debian manifesto thing Ian Murdock wrote back in '94.

What project? The title says "Open Source GTA3", but we've covered a lot of ground in here. Deciding what exactly you want to do would be the first proper step tounge.gif
Even with the similarities between 3/VC/SA, it would be best, imo, to start with one game - 3? - and just work on getting it working.

ghost of delete key
  • ghost of delete key

    ಠ_ಠ ... otter ...

  • The Connection
  • Joined: 27 Dec 2003

#19

Posted 04 February 2010 - 01:41 PM

QUOTE (DexX @ Feb 3 2010, 20:50)
There's various versions of the RWG sdk floating around as torrents or somesuch, the most common being version 3.7, but i wouldn't recommend trying to build a project around them.

I have a copy of 3.2, and no you wouldn't want to use it per se, however I've found it completely indispensible for understanding the engine and all of the RW clump/fram/atomic/extension concepts. The documentation is like the Dead Sea Scrolls of GTA to me. tounge.gif

QUOTE
If there was a project started that would re-use the existing models and textures (the "Renderware" files), i would suggest converting them to the model/texture format used by the newer engine.

I would tend to agree, but somehow I tend to stand with the purists on this one; using the raw assets as-is would eliminate the need for an installer-run (or even manual!) conversion tool. I guess it's simply a matter of preference though, since you'd need to write a capable Irrlicht loader class to handle DFF, TXD, etcetera.
I guess the caveats are: "do you wanna convert @ install, or let the game handle it natively".
In the end it prolly doesn't matter, as you could always mod the thing with any format Irrlich (or whatever) understands. You could simply plop in your .x file or .irr file or quake file or whatever...

QUOTE
QUOTE
If anyone is willing to start this project, then we need a manifesto and some stuff to go along with it, like the Debian manifesto thing Ian Murdock wrote back in '94.

What project? The title says "Open Source GTA3", but we've covered a lot of ground in here. Deciding what exactly you want to do would be the first proper step tounge.gif


Yeah, let's not get ahead of ourselves here. lol.gif Now where's our sub-forum, dammit?!?!

QUOTE
Even with the similarities between 3/VC/SA, it would be best, imo, to start with one game - 3? - and just work on getting it working.

I kinda envision one engine capable of loading all 3; you'd get the max benefit for any of the titles, so you'd have bicycles, trailers, etc. available in VC and III as well by default.
Of course, being a custom engine, the ability to turn this sort of stuff on and off at will would be built in.
The dreamers could use it all, the puritans can have Liberty City without bicycles, but of course the benefit of deformable player meshes and such.

So, has anyone looked at the Irrlicht page?
If not, see it here.
<edit> DAMNATION!!!
I spent 3 hours last night D/L-ing the 1.6.1 SDK over slow dialup (my install is 1.6.0)...
and they just put up the 1.7.0 branch today! FARK!!! cry.gif
Now I gotta do another 3 hours. However the new features look sweet.
Anyone wanna buy me a DSL subscription? tounge2.gif j/k

I ramble on pretty well, eh?

_Rob_
  • _Rob_

    Game Dev, Graphics Artist

  • Members
  • Joined: 24 Sep 2006
  • None

#20

Posted 04 February 2010 - 02:06 PM

I looked at the Irrlicht engine a while back, got it up and running even managed to render a 3ds file but that was it, it was just too hard, but the engine itself is very promisiing for a confident coder

lpgunit
  • lpgunit

    It's L, as in Lpgunit, not I.

  • Feroci Racing
  • Joined: 24 May 2008
  • Philippines

#21

Posted 04 February 2010 - 02:15 PM

QUOTE (goin-god @ Feb 4 2010, 01:04)
I dont think R* would give us the source code. They dont even help in modding.

Anyways, isn't it possible to get a "copy" of RenderWare? It shouldn't be free, but is it buyable?

I know it would not be the same, the GTA source is heavy modified, but it may help a bit.

That's why we're doing it the *other* way, like what the ReactOS team did with Windows NT 5.x/XP.

@ghost - Yeah, I'm thinking of an engine that could parse and/or interpret assets and stuff from all three GTA3-era games, although getting the one for III to work would be fine at the very least.

NTAuthority
  • NTAuthority

    member_title

  • The Yardies
  • Joined: 09 Sep 2008
  • European-Union

#22

Posted 04 February 2010 - 05:20 PM

Just thought it was time to chime in again. smile.gif A couple of things I'm thinking about for this project:

- file formats: in my opinion, it'd be best to directly use the original GTA files without conversion. The RenderWare stream formats are extensible enough to add custom sections to them as well. Pluggable file format support would be even better. (for a GTA-style engine I was planning once, I planned to have such in-engine 'converters' as well)
- pluggability: entity types, scripting engines and all that should be interchangeable. For instance, if someone wants to add a CSpaceship extension to CVehicle, it shouldn't require changing the main engine code. Most commercial game engines work that way too! Also, scripting hooks should be made clear. GTA offers choices, and making clear hooking points could allow for scripting engines to be added (Lua, SCM compatibility, raw code) easily. Even though scripting shouldn't be an issue initially, making the engine pluggable is.
- structure: instance names should be used equal to GTA's internal names. GTA3's class names should be almost completely known, which would be helping a lot... smile.gif
- re-use: using existing open-source 'middleware' code (for instance Irrlicht, Bullet Physics, some-possible-audio-library) would always be higher-quality and lesser-effort than actually coding the stuff yourself. smile.gif Also, reusing the complex mathematical stuff would require less complex mathematical stuff tounge.gif
- cross-platformness: the main code SHOULD REALLY be platform-independent! GTA, for instance, wraps code for multi-platform use in classes like CFileMgr.
- usability: things should not only work with mouse/keyboard, but also be usable with a possible gamepad/other external controller. how many times haven't I seen game projects which do not do that... (using CEGUI for instance kills that sad.gif )
- shaders: no modern game should render using fixed-function stuff. I do hope whatever engine will used has various shader helper functions (like RAGE's generic shaders, for instance)

By the way, anyone know an open-source IK (Inverse Kinematics, aka 'animation applying') calculation engine? I don't think anyone here would be qualified to write IK algorithms... tounge.gif

DexX
  • DexX

    Black Hat

  • Feroci Racing
  • Joined: 16 May 2002

#23

Posted 04 February 2010 - 10:07 PM

QUOTE
I kinda envision one engine capable of loading all 3; you'd get the max benefit for any of the titles, so you'd have bicycles, trailers, etc. available in VC and III as well by default.
Of course, being a custom engine, the ability to turn this sort of stuff on and off at will would be built in.
The dreamers could use it all, the puritans can have Liberty City without bicycles, but of course the benefit of deformable player meshes and such.

That occured to me as well, and i like the idea. But some of the stuff, such as the skin and bones for peds, changes from game to game. VC and SA should be pretty similar (sans Player-specific stuff, like clothes and changing body size), but the ped system from 3 uses different bones, and no skins (soft skinning that is, vertex deformation). The cutscenes are similar in this respect as well, using a different rigging system than vc or sa (separate head models, etc).
Related;
QUOTE
- shaders: no modern game should render using fixed-function stuff. I do hope whatever engine will used has various shader helper functions (like RAGE's generic shaders, for instance)

If there is to be any "advanced" rendering, say dynamic lighting on the map objects, then they will need to be pre-processed to add whatever data the shaders need. At the minimum, for map objects, you would need to calculate vertex normals. It's important to note, since it means several thousand models, per game, would need to be modified, and re-exported tounge.gif
I suppose whoever is coding the dff module would have the final say, but it seems a bit silly to write a dff importer and exporter, if the engine has a native format with all the capabilities necessary for whatever we want/need. The importer seems reasonable, but lets not reinvent the wheel if we don't have to.

QUOTE
- pluggability: entity types, scripting engines and all that should be interchangeable. For instance, if someone wants to add a CSpaceship extension to CVehicle, it shouldn't require changing the main engine code. Most commercial game engines work that way too! Also, scripting hooks should be made clear. GTA offers choices, and making clear hooking points could allow for scripting engines to be added (Lua, SCM compatibility, raw code) easily. Even though scripting shouldn't be an issue initially, making the engine pluggable is.
~
- re-use: using existing open-source 'middleware' code (for instance Irrlicht, Bullet Physics, some-possible-audio-library) would always be higher-quality and lesser-effort than actually coding the stuff yourself.
~
- usability: things should not only work with mouse/keyboard, but also be usable with a possible gamepad/other external controller. how many times haven't I seen game projects which do not do that... (using CEGUI for instance kills that sad.gif )

All good, valid points.

I think we have a pretty good wish list here, but we could do this forever. Any technology recommendations, or something to experiment with? GoDK mentioned Irrlicht, I'll probably poke at it and go from there.

ghost of delete key
  • ghost of delete key

    ಠ_ಠ ... otter ...

  • The Connection
  • Joined: 27 Dec 2003

#24

Posted 05 February 2010 - 01:05 PM

Here's the topic @ Irrlicht forums concerning the DFF/TXD loader.

If you want the source, look carefully as there are several versions offered throughout the 6 pages. tounge.gif

There are compiled versions to run, and I've loaded Vice with no problem.

The code is incomplete, but loads the map with most textures. 4444 is not supported though, so all of this is really Proof Of Concept - it shows what Irrlicht can do though, and looks like a promising springboard.

mortalhuman
  • mortalhuman

    CUSTOM MEMBER TITLE

  • BUSTED!
  • Joined: 12 Jan 2010

#25

Posted 05 February 2010 - 03:01 PM Edited by mortalhuman, 05 February 2010 - 04:22 PM.

Oh, this conversation. Some friends and I had it a while back, shoulda let you guys know earlier but we wanted to wait. Still do, but More info momentarily. Watch this topic. icon14.gif

Not a fan of Irrlicht tbh. It's pretty obscure and I always chose GTA above it, even though GTA had much smaller possibilities for people to actually play whatever I might work on since you have to have the game, and have it on pc, and have knowledge of modding, etc just to mod.

sparkprime
  • sparkprime

    Player Hater

  • Members
  • Joined: 05 Feb 2010

#26

Posted 05 February 2010 - 06:38 PM Edited by sparkprime, 05 February 2010 - 06:57 PM.

In about May 2007 I started writing exactly this project. We have decided to call it 'Grit'. I was new to GTA modding at the time (although I had written the Protect the Prime Minister SA-MP mode) so I had to learn all the formats and such. I chose to use OGRE instead of Irrlicht early on because its demos and screenshots were a lot more impressive, especially with respect to shadows and other advanced features. I don't know what the state of the art Irrlicht is capable of but I know many people who think it is still inferior.

There is an exporter for SA (later on I worked on it so that it supports Gostown too). Supporting dff, etc. was actually the easy part. Getting performance at scale and working with the crappy models was much harder. I had to write cache-aware algorithms and use SSE operations for some parts (besides the intense stuff the libraries are already doing). After about a year of implementing enough graphical features (LOD transitions, fades, streaming) to run the SA map I added Bullet physics support and Lua scripting. I wrote Lua bindings and ported most of the game to Lua. I wrote a HUD framework with Lua bindings and wrote a Lua console in Lua for debugging. I wrote an object framework for streaming and implemented the 'map' with it. The exporter supported graphics and collisions at this point and I recorded this:



Grit was designed with knowledge of the existence and enthusiasm of GTA modders, so it has full support for extension both in terms of individual components and total conversions. Everything is completely open in either text formats, Lua code, or known formats like .dds and .mesh.

I implemented vehicles by extending the map object classes. That brings us to end of 2008 where this video was recorded: (Pay no attention the FPS in these videos, they are tainted by the video recording process.)



I had to take a break for 9 months to write my PhD thesis (I was also working full-time). Jostvice persuaded me to implement soft shadows so I did that but progress was very slow otherwise. We also had some tough deadlines at work which took a lot of my personal time. About November 2009 I started working hard on grit again. Here is a video I recorded about the time of implementing shadows, although they work much better now:

http://www.youtube.com/watch?v=eP7pgjO8Uc4

At about this time Johnline chipped in and gave me one of his wipeout maps, so I stuck that in for a laugh, there are a few videos showing that:

http://www.youtube.com/watch?v=rsrKzz7q8I0

http://www.youtube.com/watch?v=aHKYAGdvq3M

http://www.youtube.com/watch?v=AyDC0OBokuo

Recently I implemented day/night cycles with sky gradients and all that stuff, you can see that here:

http://www.youtube.com/watch?v=gARVzn3nBsQ

K^2 recently implemented planes alongside the vehicles but we don't have a video of that yet. Jostvice is making a demo map to show off the next-gen features (SA is useless for that) like normal mapping and such but it's only partially complete. Progress is slow when the engine is being developed in tandem with the content, and there are sometimes surprises regarding what we can and can't get away with from a performance stand-point. We're also trying to implement nice blending functionality and that needs modeller support so it's all a bit clunky without proper tools. But that's game dev for you.

As this project has evolved from being a personal hobby thing into a team effort, we have had to work on usability aspects and other things that non-developers need, like custom configurations, support for foreign keyboards, etc. We now have full unicode support and you can customise your binds to use your crazy accent characters or whatever. No Chinese yet but Korean should work smile.gif

I'll try and address some of the issues raised in this thread now...

QUOTE (H13N.H3N)

if you ask me, i'm sure [Rockstar] actually will mind and a lot, because an Open Source Engine of GTA would make more or less unnecessary buying their past games or at this level, the IV version, as many of us know modeling and can reproduce vehicl


They will not mind so much if it is just an engine for their content, because people will have to buy the games in order to use it which would mean more sales for them. However if it has custom content that make it completely detached from original GTA series then it is effectively competition. There are some legal hazards here that must be avoided at all costs:

Copyright: The downloadable version must be completely free from any unlicensed files whose copyright is not owned by the project. This includes derived works, so taking an IV texture and photoshopping it until it is unrecognisable cannot be allowed. Distributing such modified textures would be illegal.

EULA: This is a bit less of a known quantity. The GTA games come with an EULA that all *users* must sign prohibiting reverse engineering, and explicitly excluding using the assets in another game. We ought not to be seen to be promoting this activity, therefore. I'm not sure on the legality of providing tools to do it. We could argue that the tools are for exporting 3rd party modder content that happens to be in GTA formats. But having screenshots / videos of the GTA games running in Grit on the site (as we currently do) is perhaps not wise.

QUOTE (H13N.H3N)

I looked at SourceForge.net just to see what i would find there,


Sourceforge search seems to be crap -- it keeps coming up with the same stuff no matter what keywords I put in smile.gif



QUOTE (ghost of delete key)

I and another member have been toying with the idea of a new scratch project with a new storyline, and this is basically our discussion at this point.


Many people have been saying this. It seems to be the way forward at this stage.



QUOTE (bammargera)

a new engine emulating every tiny detail that makes the games truly Grand Theft Auto.


In fact this is what attracted me to GTA in the first place -- while the game is broad, the gameplay elements are largely disjoint. This makes it perfect for a community project where a large number of people invest a small amount of time each, scripting individual gameplay elements. K^2 implemented planes and almost completed helicopters in a single weekend in Grit. And that was his
first exposure to the project. No reason why it can't be like this for specialist vehicles, mini-games, and whatever else you need to make the game world come to life.

QUOTE (ghost of delete key)

1) I can't run IV on my crappy box


While we can't be supporting old hardware, it doesn't stop other people from hacking the engine to work on old machines. For instance if you take out the realtime shadows, the game runs a lot faster, but then you have no shadows. What you need is some cheap decal replacement or some other alternative technique but then you have to code it. So it depends what your expectations are for running the game on old hardware. We have been aiming for GTA IV graphics and performance, anticipating that when the engine is 'ready' the kinds of hardware that can run this will be commonplace. But there are a number of cool things (think ENB series) that we are interested in implementing anyway just for the sake of it smile.gif Even if they are too slow to run on IV-level hardware. This gives a bit of future proofing.


QUOTE (ghost of delete key)

My view? I would love to see a revisitation of Vice and San Andreas with nicer GFX and ragdoll physics.


Dexx already touched on the normals issue, and let me give another example of why flogging a dead horse is not as rewarding as it might initially appear. Modern shadow techniques work by rendering the scene from the sun's perspective and writing depth into a texture. This essentially gives you a heightmap you can imagine being placed in the scene, on one side things are lit, on the other side they are dark. The heightmap has aliasing artifacts because it's a texture. These artifacts make it 'stepped' or 'jagged' so we usually work around this either by biassing it enough so that the steps don't matter, or by rendering the back faces of objects which gives you a sort of 'per model' bias. This latter approach works quite well but it places restrictions on what you can do when you are modelling. For instance if you place two polys 'back-to-back' as a sort of poor man's double-sided material, you will end up with sh*tty shadows. So without manually patching up models, you are going to have to put up with sub-standard graphics even in the presence of next-gen techniques, when re-using such old models.

QUOTE (Deji)

/me goes to learn C++
I'll tell you when I'm done, eh? xD


Seriously if you want to contribute just drop a line and we'll try to bring you onboard.

QUOTE (goin-god)

Anyways, isn't it possible to get a "copy" of RenderWare? It shouldn't be free, but is it buyable?


Flogging a dead horse applies to software as well as content, and there are much better free engines out there anyway smile.gif

QUOTE (NTAuthority)

- file formats: in my opinion, it'd be best to directly use the original GTA files without conversion. The RenderWare stream formats are extensible enough to add custom sections to them as well. Pluggable file format support would be even better. (for a GTA-style engine I was planning once, I planned to have such in-engine 'converters' as well)


I strongly dislike this idea as you have to support essentially out-dated formats that are non-standard as well as lacking the features you need. As soon as you extend them, you lose even interoperability with existing exporters so even that small advantage is lost. They are designed for the internal workings of a different engine too, which means we will inevitably have an impedance mismatch and therefore a performance problem if we do not want to repeat the mistakes of the original renderer. It also might not stand up so well in court if we try to make the claim that this is a fully independent project that just happens to support GTA formats as a cool gimmick for its users, if we are using their formats as our main formats. In Grit we took the approach of writing an offline exporter to the OGRE formats, which addresses all of these issues without compromising the goal of having the GTA data in the engine.

QUOTE (NTAuthority)

- pluggability: entity types, scripting engines and all that should be interchangeable. For instance, if someone wants to add a CSpaceship extension to CVehicle, it shouldn't require changing the main engine code. Most commercial game engines work that way too! Also, scripting hooks should be made clear. GTA offers choices, and making clear hooking points could allow for scripting engines to be added (Lua, SCM compatibility, raw code) easily. Even though scripting shouldn't be an issue initially, making the engine pluggable is.


We added cars by just extending the regular game classes, and then we added planes without changing the car classes. Scripting is implemented and works well. Debugging from the console and reloading while the game is running makes the dev cycle very tight. Of all our work I think we have been most successful in this regard.

QUOTE (NTAuthority)

- structure: instance names should be used equal to GTA's internal names. GTA3's class names should be almost completely known, which would be helping a lot... smile.gif


I don't see the point. Better that they reflect what they actually do. Also this could have legal implications if you're trying to make the claim that it's not a derived work and yet all your names are the same.

QUOTE (NTAuthority)

- re-use: using existing open-source 'middleware' code (for instance Irrlicht, Bullet Physics, some-possible-audio-library) would always be higher-quality and lesser-effort than actually coding the stuff yourself. smile.gif Also, reusing the complex mathematical stuff would require less complex mathematical stuff tounge.gif


This has been mostly successful. You inevitably find bugs in the libraries and have to go in and fix them. In some cases the developers of the libraries have been very helpful in fixing things. In other cases they showed little interest or were only able to give pointers (usually due to constraints on their own time) and we had to fix things ourselves. But in these cases they were usually happy to accept and maintain our patches, perhaps with some small changes based on their review. There are also missing features (or features that are supported but not quite in the way that you want / need). This we address by either extending or encapsulating the original features to add more features on top. As a last resort you can always target a lower level within these libraries and implement a new system alongside the existing systems.

QUOTE (NTAuthority)

- cross-platformness: the main code SHOULD REALLY be platform-independent! GTA, for instance, wraps code for multi-platform use in classes like CFileMgr.


Grit works on Linux and Windows (d3d and gl) and could also work on Mac OSX if anyone could be bothered to maintain it, write keyboard UI classes, etc.

QUOTE (NTAuthority)

- usability: things should not only work with mouse/keyboard, but also be usable with a possible gamepad/other external controller. how many times haven't I seen game projects which do not do that... (using CEGUI for instance kills that sad.gif )


We have plans to support joypads but it's not a priority at the moment. However if someone else wants to do it that would be welcome smile.gif

QUOTE (NTAuthority)

- shaders: no modern game should render using fixed-function stuff. I do hope whatever engine will used has various shader helper functions (like RAGE's generic shaders, for instance)


We are using CG for 2 reasons. Firstly it means you can write one shader instead of an HLSL shader and a GLSL shader. Secondly, HLSL compiles *very* slowly so you end up bundling precompiled shaders, but this means you can't bake in various settings for detail and such as #define macros, and is generally a pain in the arse logistically. CG is working out OK so far. We have the usual stuff like dynamic LiSPSM PCSS shadows with softness implemented with a PCF tap (size is configurable), normal maps, spec maps, etc. We also have some experimental blending effects using heightmaps implemented but it's unclear what the performance implications are at the moment. There is a feature to derive the spec map from the diffuse map, by desaturating it and applying brightness/contrast. This cuts down on texture fetches which is good for performance. We are also looking into some atlassing techniques for wrapped textures which can improve CPU performance at the expense of GPU performance and it's unclear how that will pan out.

...

OK so why haven't you heard of this project before? We don't want to keep it for ourselves, that's for sure, it's MIT licensed and you can take it and do what you want with it. But we'd rather you worked with us. So why haven't we come forward yet? There is a simple reason. While the engine is still developing, the tools are raw, the techniques are still unknown. We can't have a flood of bug reports and users asking how to do stuff only for the 'standard advice' to change a week later. We also don't want people getting the impression that it's slow or unstable when fixing these things is trivial if we just had a bit more time. For many things we already know the problem, have planned a fix, logged issues and planned out when to implement them. But if first impressions lead to opinions about OGRE/Bullet not being up to the task or that the system is broken by design warranting a complete reimplementation then that would just be nonsense and hugely detrimental to the project.

Our plan has been to get a certain amount of base functionality implemented stable and fast, and then do a first release aimed at artists and scripters. That way we could try to get some sort of playable game out of it for the next phase, while development on things like network code goes on in parallel. But right now it's not ready for that. What it is ready for is a few dedicated people who are willing to work with raw technology and nasty tools; I know for some of the best people in the GTA Modding community this shouldn't be a problem smile.gif

This forum thread kinda ruins this plan as we can't leave people in the dark if they are so clearly interested in it. And if you're going to go off and do your own project it will suffer from being 3 years behind us. Better for you to know now that this other thing is going on and how far it has come and then you can decide whether you want to join with it.

Since noone knows who I am and this is my first post I'll give a short bio: I am a 26 year old Computer Scientist working at IBM TJ Watson in New York. We are designing and implementing a new java-like language for super computers (Bluegene/P, for example) and multicore/hybrid machines that is supposed to have the performance of C++ while being as easy to code for as Java and having lots of features for concurrent / distributed programming. I did a PhD at Imperial College where I worked on new ways to implement atomic sections and did some proofs of correctness for them. My PhD thesis is linked from my academic webpage http://www.doc.ic.ac.uk/~dc04/. As well as doing the Protect the Prime Minister SA-MP mode I also did the vehicle health bars dll hack which you may have used. This was mainly to detect cheaters who would set their vehicle HP really high.

mortalhuman
  • mortalhuman

    CUSTOM MEMBER TITLE

  • BUSTED!
  • Joined: 12 Jan 2010

#27

Posted 05 February 2010 - 08:17 PM Edited by mortalhuman, 06 February 2010 - 12:59 AM.

site is changing already.

NTAuthority
  • NTAuthority

    member_title

  • The Yardies
  • Joined: 09 Sep 2008
  • European-Union

#28

Posted 06 February 2010 - 08:07 AM Edited by NTAuthority, 06 February 2010 - 08:09 AM.

QUOTE (sparkprime @ Feb 5 2010, 19:38)
I chose to use OGRE instead of Irrlicht early on because its demos and screenshots were a lot more impressive, especially with respect to shadows and other advanced features.

I have more knowledge of OGRE-related things than Irrlicht - 'a bit more than none' vs 'none' tounge.gif

QUOTE

There is an exporter for SA (later on I worked on it so that it supports Gostown too).  Supporting dff, etc. was actually the easy part.  Getting performance at scale and working with the crappy models was much harder.


Crappy? I hope you're talking about Rw's model structure... smile.gif

QUOTE

Lua scripting


Lua, Lua, everyone seems to love Lua. I don't, really tounge.gif

QUOTE

Everything is completely open in either text formats, Lua code, or known formats like .dds and .mesh.


Nice - I guess there won't be hardcoded vehicle capabilities even up to a 'tiny helicopter' list.

QUOTE

K^2 recently implemented planes alongside the vehicles but we don't have a video of that yet.  Jostvice is making a demo map to show off the next-gen features (SA is useless for that) like normal mapping and such but it's only partially complete.  Progress is slow when the engine is being developed in tandem with the content, and there are sometimes surprises regarding what we can and can't get away with from a performance stand-point.  We're also trying to implement nice blending functionality and that needs modeller support so it's all a bit clunky without proper tools.  But that's game dev for you.


... wait, this project has been existent for so long and most of us never knew about its existence? And obviously -- game development is very dependent of the assets.

QUOTE

They will not mind so much if it is just an engine for their content, because people will have to buy the games in order to use it which would mean more sales for them.  However if it has custom content that make it completely detached from original GTA series then it is effectively competition.  There are some legal hazards here that must be avoided at all costs:


Competition? Indeed, but whenever you note the things below an inspired engine wouldn't be any problem.

QUOTE

Copyright: The downloadable version must be completely free from any unlicensed files whose copyright is not owned by the project.  This includes derived works, so taking an IV texture and photoshopping it until it is unrecognisable cannot be allowed.  Distributing such modified textures would be illegal.


Well, that's obvious - but sadly the modding community is pretty lax about re-use -- but that's in GTA's own engine.

QUOTE

EULA: This is a bit less of a known quantity.  The GTA games come with an EULA that all *users* must sign prohibiting reverse engineering, and explicitly excluding using the assets in another game.  We ought not to be seen to be promoting this activity, therefore.


Well, in many countries reverse engineering is explicitly allowed, no matter what the EULAs tell you. Re-use of the assets; well, as long as you're not going to sell the engine with its conversion tools, I don't think anybody will care. And indeed, compatibility is also a valid reason as almost no game has as many user content as GTA.


QUOTE

Many people have been saying this.  It seems to be the way forward at this stage.


... indeed. As long as there are people to work on the assets, it's a possibility.


QUOTE

K^2 implemented planes and almost completed helicopters in a single weekend in Grit.  And that was his
first exposure to the project.


Extensibility is one of the main points of any modern, reusable game engine. And especially if it's a fully 'everything-is-possible' game world. No reason why it can't be like this for specialist vehicles, mini-games, and whatever else you need to make the game world come to life.

QUOTE

While we can't be supporting old hardware, it doesn't stop other people from hacking the engine to work on old machines.  For instance if you take out the realtime shadows, the game runs a lot faster, but then you have no shadows.


You shouldn't be making an non-scalable engine like GTAIV and many other modern games do. UE3, for instance, is pretty scalable.

QUOTE

This gives a bit of future proofing.


You're sounding like R* Toronto now. tounge.gif

QUOTE

[... shadow stuff ...]


Obvious. As I have already discovered, there are no 'do-all-with-anything' algorithms. SA's 'old\ real-time-shadowing method already has specific requirements to the meshes.

QUOTE
Seriously if you want to contribute just drop a line and we'll try to bring you onboard.


How can someone want to do something without any expectations? However, I would also be interested in toying around with some of the new stuff -- though I'm bad at algorithms for anything, I like hacking around on any usable stuff. tounge.gif

QUOTE
Flogging a dead horse applies to software as well as content, and there are much better free engines out there anyway smile.gif


RW is indeed old. No place to argue about that. smile.gif

QUOTE
I strongly dislike this idea as you have to support essentially out-dated formats that are non-standard as well as lacking the features you need.  As soon as you extend them, you lose even interoperability with existing exporters so even that small advantage is lost.


I was originally talking about for a case where the engine would just be a re-implementation of GTA, meant for the original assets. Obviously, for a different engine, you need different formats.

QUOTE
It also might not stand up so well in court if we try to make the claim that this is a fully independent project that just happens to support GTA formats as a cool gimmick for its users, if we are using their formats as our main formats.


Well, there are other games that use those formats? tounge.gif (jk)

QUOTE
In Grit we took the approach of writing an offline exporter to the OGRE formats, which addresses all of these issues without compromising the goal of having the GTA data in the engine.


OGRE's native formats are usable enough, as I've seen. (one thing that has annoyed me about OGRE is the configuration window every launch. I don't like that tounge.gif )

QUOTE
We added cars by just extending the regular game classes, and then we added planes without changing the car classes.  Scripting is implemented and works well.  Debugging from the console and reloading while the game is running makes the dev cycle very tight.  Of all our work I think we have been most successful in this regard.


Having everything scripted except for basic code, looks a lot like how almost every modern application should work. Fits my description of extensibility pretty well. Reloading configuration without re-initializing all map/other data - indeed, it helps a lot.

QUOTE
I don't see the point.  Better that they reflect what they actually do.  Also this could have legal implications if you're trying to make the claim that it's not a derived work and yet all your names are the same.


Again, I was talking about the 'complete reimplementation' concept. Not the 'inspired engine' concept. smile.gif

QUOTE

... reply to my 're-use' point ...


Nice to hear. smile.gif
QUOTE
Grit works on Linux and Windows (d3d and gl) and could also work on Mac OSX if anyone could be bothered to maintain it, write keyboard UI classes, etc.

That's enough for me, heh. smile.gif

QUOTE

We have plans to support joypads but it's not a priority at the moment.  However if someone else wants to do it that would be welcome smile.gif


One issue with that would be that there are two main APIs on Win32, and Linux has another API. Yes, you could use a wrapper, but that wouldn't have support for the second main Win32 API, which works completely different (XInput, it's nice for those supported controllers, but outside of that...). Also, the in-engine input handling _should_ support analog input where it fits (vehicle controls come to mind).

QUOTE
We are using CG for 2 reasons.  Firstly it means you can write one shader instead of an HLSL shader and a GLSL shader.  Secondly, HLSL compiles *very* slowly so you end up bundling precompiled shaders, but this means you can't bake in various settings for detail and such as #define macros, and is generally a pain in the arse logistically.


Never had anything to do with engine performance - and yes, GLSL/HLSL is indeed hard to both maintain at a similar level...

QUOTE
We also have some experimental blending effects using heightmaps implemented but it's unclear what the performance implications are at the moment.

There are so many nice algorithms which are just so slow that they're sometimes just unusable. sad.gif

QUOTE
There is a feature to derive the spec map from the diffuse map, by desaturating it and applying brightness/contrast.  This cuts down on texture fetches which is good for performance.


... or they can improve performance.

QUOTE
We are also looking into some atlassing techniques for wrapped textures which can improve CPU performance at the expense of GPU performance and it's unclear how that will pan out.


Many cheaper systems nowadays have a powerful CPU and a slow GPU, so unless CPU is a bottleneck (or it's just a fraction) I don't see how it could be that good an idea.

QUOTE

OK so why haven't you heard of this project before?  We don't want to keep it for ourselves, that's for sure, it's MIT licensed and you can take it and do what you want with it.  But we'd rather you worked with us.  So why haven't we come forward yet?  There is a simple reason.  While the engine is still developing, the tools are raw, the techniques are still unknown.  We can't have a flood of bug reports and users asking how to do stuff only for the 'standard advice' to change a week later.  We also don't want people getting the impression that it's slow or unstable when fixing these things is trivial if we just had a bit more time.


Provide no binaries and many of that would be solved. tounge.gif However, those users always have to spoil it for the rest of us.

QUOTE

Our plan has been to get a certain amount of base functionality implemented stable and fast, and then do a first release aimed at artists and scripters. That way we could try to get some sort of playable game out of it for the next phase, while development on things like network code goes on in parallel.  But right now it's not ready for that.  What it is ready for is a few dedicated people who are willing to work with raw technology and nasty tools; I know for some of the best people in the GTA Modding community this shouldn't be a problem smile.gif


Does that mean 'if your description of tools is a thing you need to recompile to change a parameter', that's exactly how most of my code is implemented. tounge.gif

QUOTE

This forum thread kinda ruins this plan as we can't leave people in the dark if they are so clearly interested in it.  And if you're going to go off and do your own project it will suffer from being 3 years behind us.  Better for you to know now that this other thing is going on and how far it has come and then you can decide whether you want to join with it.


Boo, you're like a huge corporation now, with the difference that you're not!

Anyway, I'm very interested in how the project will turn out, and hope to be hacking around on it sometime. Now, time to get back at discovering scripting functions in Bully.

QUOTE (mortalhuman)

site is changing already.


If there's a new site - where is it located, then? tounge.gif

ghost of delete key
  • ghost of delete key

    ಠ_ಠ ... otter ...

  • The Connection
  • Joined: 27 Dec 2003

#29

Posted 06 February 2010 - 08:53 AM

Welcome to GTAF, sparkprime!

Well, it certainly seems you've been quite busy.

Cripes, I don't think I have anything to add.

QUOTE
I am a 26 year old Computer Scientist working at IBM TJ Watson in New York.


Is that in White Plains? I used to be an electronics tech at Stahl Research Labs, we used to build "robotic" wafer inspection stations for IBM, DEC, KLA, and Tencor. IBM was our biggest customer. colgate.gif




So it seems there's no virgin snow to kick in, the tracks are already made.

Unfortunately, I'm back on dialup, so a minute of video takes 45 minutes or so to buffer and usually punks out before it finishes; I'll not be able to see your vids any time soon. angry.gif

Any stills?

It sounds enticing, although I'm not sure I'd be able to contribute anything that hasn't already been done.
But I'm all ears anyway. biggrin.gif

JostVice
  • JostVice

    realtime, not prerendered

  • Feroci Racing
  • Joined: 30 Oct 2005
  • None

#30

Posted 06 February 2010 - 03:12 PM

grit engine is pretty promising. I'm working with him modelling and giving ideas for how the structure should be (from my experience with gta modding)

Right now there aren't much pictures as there isn't any serious project (every model is a placeholder to test features. Right now we're playing with blending different materials using different vertex colors for each material with a heightmap for the fading effect)

QUOTE
was originally talking about for a case where the engine would just be a re-implementation of GTA, meant for the original assets. Obviously, for a different engine, you need different formats.


Why would you want to load the original assets?

QUOTE

QUOTE
There is an exporter for SA (later on I worked on it so that it supports Gostown too).  Supporting dff, etc. was actually the easy part.  Getting performance at scale and working with the crappy models was much harder.


Crappy? I hope you're talking about Rw's model structure... smile.gif


He probably means crappy in the sense of very lowpoly, without normals and with a high amount of drawcalls.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users