Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Graphics wizardry
#16
If you'd paid attention to Bob, you'd know the i7 won't make a difference. You get 1 core for YR. Period. You'll do fine either way. The 920 is 2.66 IIRC and that's more than enough juice for YR.

Then again, I'll find out when I get my i7 and GTX285. XD
I'm what Willis was talkin' about.
Reply
#17
(23.04.2009, 07:29:06)Beowulf Wrote: If you'd paid attention to Bob, you'd know the i7 won't make a difference. You get 1 core for YR. Period. You'll do fine either way. The 920 is 2.66 IIRC and that's more than enough juice for YR.

Then again, I'll find out when I get my i7 and GTX285. XD

Yay we have would have snap rigs XD!
Reply
#18
That was unnecessary. Let the thread die in peace.
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#19
ok, lets stop talking about your penis extentions, and get back to the task at hand

lol

anyway, Although i can say, YR doesn't really interest me anymore, and i'm... A retired veteran modder, this is actually 1 feature that interests me, and it would be fun to play around with at some point, to see what the best operating mode is on different PCs.
Reply
#20
^^^ Agree this is the most important feature. adding this would make ares even bigger!

- Use Graphic card instead of CPU
- Use all CPU cores if you have more than one
Reply
#21
Yeah, come on D, hurry up and add
UseGraphicCard=yes and UseAllCPUCores=yes
What's taking you so long?!

And to any of you who didn't detect the sarcasm and think the above demand is reasonable, please return to kindergarten and stay there.
Ever wondered what the hell is going on?
Believe me friend you're not the only one.
--Lysdexia

Check out Launch Base for RA2/YR - http://marshall.strategy-x.com
Also home to the Purple Alert mod, 1.002 UMP, and the YR Playlist Manager.
Reply
#22
(25.04.2009, 12:35:51)Marshall Wrote: Yeah, come on D, hurry up and add
UseGraphicCard=yes and UseAllCPUCores=yes
What's taking you so long?!

And to any of you who didn't detect the sarcasm and think the above demand is reasonable, please return to kindergarten and stay there.

lol I know this is very hard and it is not just add a new tag. What I was trying to say, even if it take very long time it will be worth it
Reply
#23
lol

YR already has five threads, actually. And, Bob, don't forget that with multithreaded programming come race conditions and fun times with synchronisation. Do you want to spend two weeks tracking down a random IE that turns out to be caused by thread A increasing the BuildingTypeClass::Array length while thread B is iterating over it?
Reply
#24
I didn get a thing you wrote, D, but I think it makes sense... (It doesn't have to, though) Big Grin
ALL HAIL!!!! King of the Loosers
ugh.. Never mind..


[Image: 9c3cfb081d.png]

"Engine 2 is 'no longer' on fire." -One of those penguins from Madagascar (though, I can't seem to recall that guy's name.. Nay, who cares?)
Reply
#25
(26.04.2009, 14:26:59)Tempest Wrote: I didn get a thing you wrote, D, but I think it makes sense... (It doesn't have to, though) Big Grin

in other words "pricking about with multithreading will most likely fuck the game and cause too many headaches"
[Image: MRMIdAS2k.jpg]
MRMIdAS: No longer allowed to criticise Westwood on PPM
Reply
#26
(25.04.2009, 15:24:10)DCoder Wrote: lol

YR already has five threads, actually. And, Bob, don't forget that with multithreaded programming come race conditions and fun times with synchronisation. Do you want to spend two weeks tracking down a random IE that turns out to be caused by thread A increasing the BuildingTypeClass::Array length while thread B is iterating over it?

you know what i mean though, they didn't set up those re-synchronisation routines to make use of more than 1 core at once. I'm probably 1 of the Minority, like you, who can understand how much of a headache it can be.
Reply
#27
(25.04.2009, 15:24:10)DCoder Wrote: lol

YR already has five threads, actually. And, Bob, don't forget that with multithreaded programming come race conditions and fun times with synchronisation. Do you want to spend two weeks tracking down a random IE that turns out to be caused by thread A increasing the BuildingTypeClass::Array length while thread B is iterating over it?

I am guessing hyper threading doesn't help at all because thats the same thing in theory right?
Reply
#28
Hyperthreading is just the illusion of multiple cores. It's still just one core in reality but it can be applied to multi-core processors, as well.

Also, for the record Bob, I understand threading across cores myself. You and D aren't the only ones.

Anyway, I digress. How goes the graphics wizardry, D?
I'm what Willis was talkin' about.
Reply
#29
Has this been enabled yet?
Reply
#30
Hey guys, has any of you tried the "magic" ddraw.dll on Windows 7? Comedy.

1. INI Controls
I implemented the INI controls now, but the surfaces are created before the rules are even read, so I can't really put them there. And I can't put them in RA2MD.ini, since that is rewritten from scratch on every exit. Writing the data into ra2md manually is an option, but the next time you run plain YR without Ares, guess what will happen to these new settings. So I had another thought: are there any objections to me creating an ares.ini instead, and sticking them there? I'm sure we'll come across more settings that only make sense on a global scope like this.
Some mods might want to force specific settings on the user, and mod-switching needs to be aware of that eventually...

2. Windows 7
At least on Windows 7, the ddraw.dll draws nothing, and switching it to hardware accel only crashes real hard. So in there, the DirectX.Force= setting will be ignored and the game will run as it used to. Yeeeeaaaaah.
Edit: Rereading the ddraw.dll thread, I found mention of it also being useless on Vista. Not surprising.

3. Other info related to drawing
Thanks to Westwood's way of drawing, you should actually prefer the surfaces in system RAM, not GPU.
This means disabling the VideoBackBuffer is the right thing to do... maybe I should actually make YR default to that mode? Who knows...

Note for clarity's sake: contrary to wthigon's claim in the old ddraw.dll thread, that dll and VideoBackBuffer are two different things.
ddraw.dll tells DirectX to not use any hardware acceleration on graphics.
[Video]VideoBackBuffer = no (not default) and AllowVRAMSidebar = no (default) tell the game to place all the surfaces in system memory.

Blit counter: It only works when the Tile surface is in VRAM (GPU) , and the Alternate surface is not. That is the default config...

In a short while the testers will get the new build with the options from first post available, even though I should advise you not to expect miracles, we'll see what results we get back.
Reply




Users browsing this thread: 1 Guest(s)