+- Renegade Projects Network Forums (https://forums.renegadeprojects.com)
+-- Forum: Inject the Battlefield (https://forums.renegadeprojects.com/forumdisplay.php?fid=60)
+--- Forum: Ares General Discussion (https://forums.renegadeprojects.com/forumdisplay.php?fid=19)
+--- Thread: Graphics wizardry (/showthread.php?tid=1259)
RE: Graphics wizardry - Beowulf - 23.04.2009
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
RE: Graphics wizardry - hogo - 23.04.2009
(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!
RE: Graphics wizardry - Renegade - 23.04.2009
That was unnecessary. Let the thread die in peace.
RE: Graphics wizardry - Bobingabout - 24.04.2009
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.
RE: Graphics wizardry - Guest - 24.04.2009
^^^ 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
RE: Graphics wizardry - Marshall - 25.04.2009
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.
RE: Graphics wizardry - Guest - 25.04.2009
(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
RE: Graphics wizardry - DCoder - 25.04.2009
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?
RE: Graphics wizardry - Tempest - 26.04.2009
I didn get a thing you wrote, D, but I think it makes sense... (It doesn't have to, though)
RE: Graphics wizardry - MRMIdAS - 26.04.2009
(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)
in other words "pricking about with multithreading will most likely fuck the game and cause too many headaches"
RE: Graphics wizardry - Bobingabout - 27.04.2009
(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.
RE: Graphics wizardry - hogo - 27.04.2009
(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?
RE: Graphics wizardry - Beowulf - 04.05.2009
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?
RE: Graphics wizardry - hogo - 18.06.2009
Has this been enabled yet?
RE: Graphics wizardry - DCoder - 15.11.2009
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.