Instalar Steam
iniciar sesión
|
idioma
简体中文 (chino simplificado)
繁體中文 (chino tradicional)
日本語 (japonés)
한국어 (coreano)
ไทย (tailandés)
Български (búlgaro)
Čeština (checo)
Dansk (danés)
Deutsch (alemán)
English (inglés)
Español de Hispanoamérica
Ελληνικά (griego)
Français (francés)
Italiano
Bahasa Indonesia (indonesio)
Magyar (húngaro)
Nederlands (holandés)
Norsk (noruego)
Polski (polaco)
Português (Portugués de Portugal)
Português-Brasil (portugués de Brasil)
Română (rumano)
Русский (ruso)
Suomi (finés)
Svenska (sueco)
Türkçe (turco)
Tiếng Việt (vietnamita)
Українська (ucraniano)
Comunicar un error de traducción
So when a bug of this kind appears, it is near impossible to find the cause of it. I would suspect it has to do with console HDD fragmentation, which is more likely on retail consoles that had a lot of different games played on them. But we tried to fragment our dev drives with syntetic tests, but couldn't reproduce this. The only way to debug this kind of thing is to play until it does that pause, then quickly stop the code and examine where it is in the debugger. But we cannot do that with the retail consoles.\
Shrug.
Definately!
i would also consider the fact that these companies use hardware that is budget or simply put cheap. for instance you guys siad they use an old CPU. if the CPU is old than that could just be the problem there. just to damn old. the game was developed as a pc game i know that which means it could have been difficult for a console release in some areas (console CPU obviously). also it could be console ram as well. i dont think the GPU in the xbox 360 has much video ram. i dont know how much the xbox one has either. imagine my mid range system here that runs a AMD X2 II 240 2.80 proccessor (which by the pc community is considered old) and a mid range GTX 650 being more next gen than the xbox one. for all i know thats what the xbox one is running or something equaivalent to it
Edit: Also of note was that the 360/PS3 cpu's were made in a time when "clock speedz" were still the defining factor for processor performance.
SS3 will be exclusive for Tegra K1(or Tegra 4 and K1), or it's coming to non-Tegra devices too?
There are several that are in the Tegra4 class and if the game will work on Tegra4, it might (*) work on them too. But if we don't manage to backport to T4, then only after there are some other K1-class devices. I don't know of any yet even planned, though.
Some of our future games will be more friendly towards lower-end hw, and thus run on Tegra4-class.
(*) Note though that nvidia's drivers are top of the line. I expect a lot of driver problems with other vendors and that may be a very limiting factor.
Will it be Serious Sam: FE or Serious Sam: SE?
Unlike that PVR demo, K1 was running several real games at the GDC. SS3 being one of them. I know I may be sounding like a shill by now, but I'm genuinely impressed by K1. Honestly, we work with it daily, and we treat the platform just about like a semi-powerful gaming laptop. It's hard to express all the programming disbelief in mere existence of something like that. If it wasn't for the Android OS, I'd think that this is a Windows PC.
Now, perhaps I'm mistaken because I don't have developer boards for those other vendors. But what's keeping them from sending some to us - if they have them. Hint, hint... ;)
This is something that I was hinting at for months already, and it will come. We will be retrofitting all of the older games (the HD versions, not the classics), onto all the new platforms as we come to support them. But more on that later. So, in short - yes, there will be SSHD:TFE/TSE on Android (as well as OSX, Linux...) - at a point. Actually, we can more-or-less run those already, besides the SS3. It just needs some more fixes and tuning to be available at the same time. You'll hear more about it when the time comes.
Just curious: what max resolution of rendering in Serious Sam 3 on Tegra K1?