BeamNG on RAGE

Hi guys, I'm new to this forum.

I've registered here mainly because of this theme about the BeamNG engine ported on the RAGE one.
I've been reading this post and as far as I saw, this engine can be used in any game, but I've still got a question to ask all of you:
Are you guys actually working already to make this happen? Will it even be possible? When exactly?
If none of you thought about this or you guys aren't interested at all, I swear that I will do everything possible to make this happen.
The only problem is that I don't have any knowledge related to this, and I blame myself for not having it, but really guys, there are alot of GTA fans which as me want this engine to be ported into a GTA game (preferably on GTA V if it will ever come to PC this year).

Anyways I will be waiting for a reply which It would be really appreciated.
And also, forgive me if I might sound ignorant about all this, I'm just a GTA fan who wants to have a realistic game and have fun while playing with this amazing engine on a GTA game.

Greetings!

 

Considering how much work the Devs have put into perfecting Torque3D, and the amazing results they have achieved, I would say that the chances of BeamNG using Rage is nil. I'm no expert in this area, but I imagine that trying to rebuild GTA IV to run on Torque3D is practically impossible, and most likely illegal. The best thing you could do is have terrain and vehicle mods from those of GTA (e.g Liberty City terrain, Futo & Sultan RS car mods). Of course, they would have to be modeled yourself, as using Rockstars models is not allowed for legal reasons

 

Thank you for replying to my question, it was very helpful and it kind of chilled me out a bit, even though I'm not glad to see it happening in 5-10 years as you said, it's way too far in my opinion.
However I will stay tuned and somehow (if possible) help anyone who already thought of planning this project by now, although I respect and appreciate the work that the Torque3D/BeamNG developers do everyday with the physics and such things.
I won't actually give up on this and I will keep on hoping to see if something new pops up about this theme.

 

they [BeamNG devs] are predicting that in a years time or so computing technology will be able to handle twice as many cars as the average quad core CPU can now

 

Actually thats just Moore's Law.

 

Fascinates me the accuracy of this. I need to do some more research on Moore's law. There are some processors on that list I've never heard of.. Intanium dual core, amd k10? Sauce on these?


1,000th post

 

http://www.extremetech.com/gaming/1...nthusiast-chips-and-desktop-broadwell-details

And they will be real 8 cores, not what AMD does with 4 modules or something like that claiming they have 8 cores.

 

Itanium is another processor architecture that Intel make. No relation to x86 beyond Intel owning it. Aimed at servers, not very popular and already being phased out I believe. It went toe to toe with IBM Power and Oracle/Sun Microsystems SPARC.

K10 is the microarchitecture used in the newer Athlon, phenom and older opteron series chips the same way that current core i3/i5/i7/Xeon chips use the haswell microarchitecture.

As for accuracy, late 2011 through to now are not accounted for and the law is beginning to taper off a little. But then we are always finding ways of increasing efficiency without increasing transistor counts too.

1 AMD module consists of 2 true hardware cores so to label 4 modules as 8 cores isn't just a worthless claim, its actual fact.

 

One AMD module has two integercores. a hardwarecore is much more than a integercore.
Adding a additional integercore to a singlecore doesn't make it a dualcore.

 

2 arithmetic logic units (integer core, lol, off to a great start on demonstrating your computer systems knowledge mate), 2 sets of pipelines (actually 4 pipelines per core), 2 individual sets of registers, 2 L1 cache's. Each ALU functions totally independently as its own execution core.
There are only 3 things which are shared between 2 cores inside an AMD module.

• L2 cache. Whether or not L2 cache is shared or not does not change the distinction of whether the 2 cores are 2 cores or 1. L2 cache simply serves as a buffer between L1 cache (which is independent per core) and main RAM. There is the potential for collisions in the L2 cache, but with it being a full 2mb in size this is unlikely at best and something which any compiler worth its salt can avoid.
• Floating point hardware. There is only a single floating point unit in a module. However a microprocessor does not have to have floating point hardware at all so again this shouldn't impact whether a module is 2 cores or not. On top of that the floating point unit in an AMD module has 2 seperate interfaces, 1 to each core and can perform 2 pieces of 128 bit arithmetic simultaneously (1 for each core, hence serving as 2 independent 128 bit FPU's) or can function as a single 256 bit FPU. This is actually the only major sticking point in the architecture as there are very few safety mechanisms in place for preventing the 2 cores from performing 256 bit arithmetic at once, however 256 bit floating point arithmetic is incredibly rare to the point that most major OS's dont support the hardware at all and will still perform a software fallback, the few applications that will use it can specifically be optimised to account for the shared module.
• Instruction prefetcher. Similar to the floating point unit in that it is implemented as a single component, however does have seperate interfaces for each core and will fetch 2 instructions at once for each core.

 

1. The microarchitecture amd uses is called "Clustered Integer Core". That's why i called them integer cores. A better name would be Integer Clusters.
2. Integer Cluster != arithemic logic unit. One Integer Cluster has 2 ALUs, 2 AGUs, a scheduler, a L1 cache and some more components.
3. One intel core has 4 ALUs and 3 AGUs, a scheduler, a L1 cache, ...
-> one AMD module can do 4 arithmetic operations at once, as well as ONE Intel core (and that's without hyperthreading)

You forgot the L3-(and L4-cache if existing) Since the L2-cache in the amd is that big, i think this can even be a advantage since collisions are unlikly and data can be shared much faster between cores than on intel-cpus (which would need to use L3-cache afaik, which is much slower)

- one amd module (2 "cores") can do 1 256 bit arithmetic or 2 128 bit calculations at once.
- two intel cores can do 2 256 bit arithmetic or 4 128 bit calculations at once. (also without hyperthreading)

Its not only the instruction prefetcher but also the actual decoder and the dispatcher(which is actually the component, which does have the interfaces to the two Integer clusters and the FPU).

Conclusion: One Intel core is nearly as powerful as a AMD module. Important parts of the AMD module are NOT existing twice. For integercalculations its nearly a dualcore, for floatpointoperations its a singlecore.

Also, is that really necessary? If you try to show me how superiour your knowledge is, you should make sure, the things you say are right. Makes you look like an idiot otherwise

 

Everything I didn't quote, I'll hold my hands up and say that you may have more knowledge than I do.

Didn't forget. Simply determined it to be irrelevant as all cores on an intel device share L3 and all modules on an AMD device share L3 and hence I decided it has no impact on the pros or cons of AMD vs Intel, any comparisons of AMD vs Intel in regards to L3 cache can only really be made in regards to size and latency. L4 cache is used on Intel haswell devices with the onboard Iris GPU and on Itanium (it features in no other Intel products), its pretty massive though at 128mb (64 on Itanium), it is DRAM based though whereas L1 through L3 are usually SRAM and in the case of haswell+iris is primarily intended to serve the GPU but of course the CPU does still have to buffer through it so may see some gains.
AMD appears to have a small shared level of L1 cache per module aswell as a split section, they dub it L1i (shared) and L1d (not shared), L1i stands at 64kb, L1d 16kb, L2 2mb and then finally the shared l3 cache at 8mb.
Intel I couldnt find the L1 cache size. But the L2 on any haswell chip with either celeron, pentium or i3 branding is 512kb, i5 depending on model is either 512 or 1024kb and then on all i7's its 1024kb. L3 is 2mb on celeron branded chips, 3mb on pentium, 3 or 4mb depending on model of i3, 4 or 6mb depending on model of i5 or 8mb on i7. So on certain models i5 and on the i7's, 1 core is pretty much on par with each half of a module for the amount of L2 available, but other models fall behind and all models fall behind on L3, I think its always been "a thing" that AMD has a larger cache though, before counting L4 anyway but considering that L4 is only implemented on a non x86 chip and on a chip utilising it primarily for GPU usage I think we can discount that as specialist.

In recent years Intel has hammered AMD for most single threaded tasks. If you take an absolute best case scenario for hyperthreading (30-40% gain supposedly, although the worst case scenario has been reported to be as much as -50%) it really wouldnt surprise me if Intel does genuinely creep ahead. I'm not here to dispute whether intel or AMD is more or less powerful. Although if you take AMD to be 1 module = 1 core and therefore pit a 4 module AMD chip against a 4 core intel chip, AMD almost always seems to gain the upper hand in multithreaded benchmarks.

Could that not be turned around on your original post?



My stance: Yes 2 cores in 1 module share some resources. But they do still function almost entirely independently, the state of 1 is not dependent on the other, they can operate on 2 entirely different tasks with the only collisions being *potentially* in the L2 cache or when they go to do 256bit floating point arithmetic in hardware (unlike hyperthreading which does regularly suffer from collisions to the point that modern operating systems specifically require code to avoid this). I see no reason to combine them and label them as 1 core.

 

All of these PhD in computer science people in here.. Anyways I don't see any reason to use rage. The engine they have built is perfect for the direction its heading. There will be a day when people want to use beamng's engine for their games. It's a very unique engine that was developed by a couple programmers.. I like dat.

Sent from my SCH-I545 using Tapatalk

 

I think BeamNG itself is independent of torque so could probably be bolted onto the side of rage if the tools for interacting with rage so heavily actually existed (which they dont).

 

STAHP USING THESE BIG COMPUTER WORDS IT MAKES ME FEEL STUPID AND SIX SHOULD ALREADY HAVE HIS MASTERS DEGREE WITH THIS STUFF.

Just as soon as I recognize the majority of what tech stuff you guys say on here, this thread comes on my screen and makes me fall back by about 74% in how smart I feel with it. :|

 

Not sure how relevant this is with beamng. But with my time playing with the terrain editor I like how it works. I wish you could be more in depth with some details. It works off a very dense grid.

Sent from my SCH-I545 using Tapatalk

 

Its all good bud I understand like 60% of it. The other bits are simple to learn. But I don't know it all either lol

Sent from my SCH-I545 using Tapatalk

 

I bet if I read it a few times, I would get it.

Also, which phone do you have? Is it a Stratosphere?

 

Just because i don't see a module as a dualcore, it doesn't mean i see it a s a singlecore either. Its something inbetween. More performant than a single core, less performant than two cores.

The part that annoyed me wasn't that you were wrong, but the attitude of that part:

Therefore no, it can't be turned around to my first post.
Besides, calling them cores would help your argumentation, since those integer clusters are the only components that are existing twice.

My problem with calling it dualcore is simple. Looking at the architecture, they used a single core and just added a integer cluster. then they added interfaces to the fpu and the dispatcher so they can communicate with both clusters. that's it.
So it has nearly the speed of two cores when it comes to working with integers (nearly, because precode, decoding and dispatching works the same way it would for a single core). But when it comes to floatpoint operations is as slow as a single core (because it essentially is).
That, combined with the fact that intel is better when it comes to single core performance (and in my opinion in coordinating multicore) is the reason why intels are much better for gamingrigs. when it comes to 3dengines and physics you have a ton of floatpoint-operations and only very few integer-operations. (Just to bash AMD a bit )

But i'm glad we could discuss this in a mature way. looking at the forums, that isn't the norm