Odd, I take the 96 tram to work all the time and there's almost never enough room to use a laptop (especially during the busy work hours). Unless he's that dude typing furiously with one thumb into his wifi enabled cellphone, I find this a little hard to believe.
I didn't suggest using no abstraction, just pointing out that overuse of abstraction yields minimal gain in productivity and introduces more overhead than necessary. If you are happy to pay that overhead, that's fine, it just happens to be another cost that dwarfs the constant overhead in addition to bad algorithms.
Of course competent programmers do not need trash collection, but it sure makes life easier, and can cut down on programming hours.
As someone coming from C++ and is just starting to port over to C#, I actually find the GC more of a hindrance than a help a lot of the time. Sure, being able to new something without having to think about when to delete later may seem useful at first, but I spend more time fighting against the GC trying to convince it to clean up and avoid fragmentation in the Large Object Heap, handle COM reference counts safely without waiting for the GC to clean up C++ side objects (it proxies through the RCW which holds a single reference until someone forcibly releases it in an unsafe manner or waits for the GC to clear the RCW) or just be able to throw away a collection and create a new one without worrying about allocation failures as a result of the GC not being aggressive enough. A smart pointer that deletes when going out of scope or reference count going to zero isn't that difficult to learn in C++ and gives more control when you want to try to do something fancy.
Or abstraction on top of abstraction on top of abstraction. Garbage collectors and JIT compilers etc are all well and good until you realise how much overhead they add to certain tasks.
As it starts swapping data to your 1960's technology (aka Hard Drive) the whole system slows to a crawl while your super fast memory and super fast CPU waits forever for read/write heads just to move around.
You keep believing that the memory is super fast. CPUs are getting a heck of a lot faster rather quickly, but the memory latency isn't decreasing much. This means that it takes more and more CPU cycles just to fetch data from RAM.
Android is an open source OS based on Linux that can run natively compiled applications. The official SDK however is Java based, but that doesn't make it impossible to run C apps.
You can't just render half a model on both screens, if your person character is 2 million polys you have to render the whole thing.
The only exception to this is when applying level of detail which is normally used only on distant objects because doing so makes the whole model ugly.
And as I already said, since the viewport is smaller you can get away with that effect to some extent (it will be rendered as a smaller object which is the same reason why distant objects can take the shortcut). I did say in my example that halving the polygon count is a bit extreme, but it emphasises that there are shortcuts available to reduce a doubling of the workload. Take a look at the Unigine Heaven benchmark tool with wireframe mode enabled to get a good view of how polygon count is dynamically scaled based on distance from the viewport, and that metric can be weighted by the number of split screen views.
Also consider what peformance effect changing the screen resolution has. Even without changing polygon count and other shortcuts, you will notice a higher framerate when you halve the number of pixels required for rendering. Splitting the screen clearly reduces the pixel count per rendering target. You still end up producing the same number of pixels overall when compared to a single screen render, but you don't pay that toll twice.
Did you not read the part where I said "using half the number of polygons"? Render 2 million polygons once, or render 1 million polygons twice. It won't be the same workload, but it won't require twice the resources either.
I didn't say it was automatic. I suggested that they can get away with using less polygons when rendering to a smaller viewport. As an extreme example, using half the number of polygons in the world and rendering that twice from different viewports doesn't double the workload.
Hey that sweater you're wearing is red like my uncle's car. Your wearing my uncle's car. Spot the difference?
Hey that sweater you're wearing is red like my uncle's sweater.
Hey that sweater you're wearing is red like my uncle's ugly sweater.
Apologies for diverting from the car analogy (hey, at least it made an appearance in this thread), but can you spot the difference now? They stated the feature was co-op (which by definition is already multiplayer) then went on to say it has aspects like a massive multiplayer (which adds absolutely nothing but a massive modifier, or in my example ugly).
Rendering split screen takes up a huge amount of resources. Think about it.
That also applies to older consoles, and newer consoles have faster hardware to handle the hit if they so chose. I have thought about it.
You're rendering everything twice and then applying lighting shader models to both.
Yes, and since you are rendering to a smaller area with less pixels, you can get away with a smaller polygon count and other shortcuts. It won't be twice as much work.
If you're trying to push the graphics on a first gen game then you're not going to be able to when you're doing split screen.
True. Also applies to older consoles, but newer games tend to try to tax the hardware more (whether it's an attempt to out-bling the competition or lazy optimising or abstraction overhead) so I'll give you that. It's not too difficult though to use lower quality settings for split screen mode.
Not only this however you have to debug and test the game twice. That's expensive, why bother?
They have to debug and test on the multiple consoles plus PC that this game seems to be targeting anyway. Testing an added feature doesn't generally involve retesting the whole game, they sample areas that are likely to be of interest. Also, games of today are inherently less tested due to the possibility of live patching. They don't bother as much as they used to.
You can not compare a NES game which is limited in scope of game play to a game of today. Why did you even bother to mention this?
I said all other consoles, not just the NES. The PS2 had the ability of network play, for example. Also, I mentioned it because all the arguments you have made thus far also apply to the older consoles. Heck, the Wii is current seems to be able to handle split screen games and has internet capabilities.
You mean like the NES right? You realise games like super mario kart were built with their primary goal being split screen right?
Sure, like the NES. Considering Super Mario Kart was made for the SNES, not NES.
It's not some kind of feature you can just tack on. It effects everything from sound, input, UI and on.
Since modern programming uses multiple levels of abstraction all over the place (partly for convenience, partly for portability), it is getting a lot closer to being something you can "just tack on".
Microchips aren't urgent. It doesn't matter if the batch you will send tomorrow arrives in 3 months, as the batch you sent 3 months ago arrives tomorrow (apologies for randomly made up numbers). If you have massively high volume stuff, you just ship it in volume using a pipeline approach.
His actions caused a lot of deaths, he faked his own death and has now taken an alias as a philosophical programmer trying to make up for all his wrongs.
And doing split screen would increase development time, debugging and testing on the other consoles too. You failed to explain how it is unique to the current consoles.
Tried it, had I read this post 5 hours into playing it I would have agreed with you. Come hour 6, I lost all interest as it didn't get more interesting as I went along. The whole point of Torchlight was to introduce the back story for the MMO, which is strange because that's the key component that Torchlight lacked. Some lady keeps showing up at checkpoints at regular intervals telling you to go deeper, you go deeper. The quests and maps don't vary enough.
It had great music, good graphics, acceptable gameplay (although higher level spells were lacking) and no story.
The advantage of Diablo was how long Blizz supported it with patches. What are the odds Bethesda will fix any [...] issues [...] before or after release?
You mean the flesh and bone one that's probably decomposed somewhat? I guess it could become a zombified boss to kill or something, but I doubt you would want to stick a rotting leg in your absurdly large pocket next to the 6 plates of armor.
I believe that you are taking the whole "get of my lawn" think a bit too seriously.
They took issue with you claiming "Diablo clone" is wrong and "Roguelike" is correct, not with an attempt to continue what many consider to be a lame meme involving turf.
In case you are new here
Says someone with a higher UID to someone with a lower UID (irony of myself doing the same is noted).
You are taking what I intended to be a comical jab, and use it as the basis for a serious, and non-trivial discussion.
Perhaps you could just voluntarily get off their lawn?;)
It was implied. If they didn't want to imply the "massively" component, they could have just said mulitplayer or MO or something equivalent (or just leave it as co-op).
Slashdot Mirror
Odd, I take the 96 tram to work all the time and there's almost never enough room to use a laptop (especially during the busy work hours). Unless he's that dude typing furiously with one thumb into his wifi enabled cellphone, I find this a little hard to believe.
I didn't suggest using no abstraction, just pointing out that overuse of abstraction yields minimal gain in productivity and introduces more overhead than necessary. If you are happy to pay that overhead, that's fine, it just happens to be another cost that dwarfs the constant overhead in addition to bad algorithms.
Except for the fact that most of the bloated and slow programmers in Windows and Loonix are written in either C and C++.
A human written in either C or C++?
Of course competent programmers do not need trash collection, but it sure makes life easier, and can cut down on programming hours.
As someone coming from C++ and is just starting to port over to C#, I actually find the GC more of a hindrance than a help a lot of the time. Sure, being able to new something without having to think about when to delete later may seem useful at first, but I spend more time fighting against the GC trying to convince it to clean up and avoid fragmentation in the Large Object Heap, handle COM reference counts safely without waiting for the GC to clean up C++ side objects (it proxies through the RCW which holds a single reference until someone forcibly releases it in an unsafe manner or waits for the GC to clear the RCW) or just be able to throw away a collection and create a new one without worrying about allocation failures as a result of the GC not being aggressive enough. A smart pointer that deletes when going out of scope or reference count going to zero isn't that difficult to learn in C++ and gives more control when you want to try to do something fancy.
Or abstraction on top of abstraction on top of abstraction. Garbage collectors and JIT compilers etc are all well and good until you realise how much overhead they add to certain tasks.
As it starts swapping data to your 1960's technology (aka Hard Drive) the whole system slows to a crawl while your super fast memory and super fast CPU waits forever for read/write heads just to move around.
You keep believing that the memory is super fast. CPUs are getting a heck of a lot faster rather quickly, but the memory latency isn't decreasing much. This means that it takes more and more CPU cycles just to fetch data from RAM.
You heard wrong. That accomplishment belongs to Al Gore.
Android is an open source OS based on Linux that can run natively compiled applications. The official SDK however is Java based, but that doesn't make it impossible to run C apps.
You can't just render half a model on both screens, if your person character is 2 million polys you have to render the whole thing.
The only exception to this is when applying level of detail which is normally used only on distant objects because doing so makes the whole model ugly.
And as I already said, since the viewport is smaller you can get away with that effect to some extent (it will be rendered as a smaller object which is the same reason why distant objects can take the shortcut). I did say in my example that halving the polygon count is a bit extreme, but it emphasises that there are shortcuts available to reduce a doubling of the workload. Take a look at the Unigine Heaven benchmark tool with wireframe mode enabled to get a good view of how polygon count is dynamically scaled based on distance from the viewport, and that metric can be weighted by the number of split screen views.
Also consider what peformance effect changing the screen resolution has. Even without changing polygon count and other shortcuts, you will notice a higher framerate when you halve the number of pixels required for rendering. Splitting the screen clearly reduces the pixel count per rendering target. You still end up producing the same number of pixels overall when compared to a single screen render, but you don't pay that toll twice.
I agree with what you say, but it has little to do with urgency.
Did you not read the part where I said "using half the number of polygons"? Render 2 million polygons once, or render 1 million polygons twice. It won't be the same workload, but it won't require twice the resources either.
I didn't say it was automatic. I suggested that they can get away with using less polygons when rendering to a smaller viewport. As an extreme example, using half the number of polygons in the world and rendering that twice from different viewports doesn't double the workload.
Hey that sweater you're wearing is red like my uncle's car. Your wearing my uncle's car. Spot the difference?
Hey that sweater you're wearing is red like my uncle's sweater.
Hey that sweater you're wearing is red like my uncle's ugly sweater.
Apologies for diverting from the car analogy (hey, at least it made an appearance in this thread), but can you spot the difference now? They stated the feature was co-op (which by definition is already multiplayer) then went on to say it has aspects like a massive multiplayer (which adds absolutely nothing but a massive modifier, or in my example ugly).
Rendering split screen takes up a huge amount of resources. Think about it.
That also applies to older consoles, and newer consoles have faster hardware to handle the hit if they so chose. I have thought about it.
You're rendering everything twice and then applying lighting shader models to both.
Yes, and since you are rendering to a smaller area with less pixels, you can get away with a smaller polygon count and other shortcuts. It won't be twice as much work.
If you're trying to push the graphics on a first gen game then you're not going to be able to when you're doing split screen.
True. Also applies to older consoles, but newer games tend to try to tax the hardware more (whether it's an attempt to out-bling the competition or lazy optimising or abstraction overhead) so I'll give you that. It's not too difficult though to use lower quality settings for split screen mode.
Not only this however you have to debug and test the game twice. That's expensive, why bother?
They have to debug and test on the multiple consoles plus PC that this game seems to be targeting anyway. Testing an added feature doesn't generally involve retesting the whole game, they sample areas that are likely to be of interest. Also, games of today are inherently less tested due to the possibility of live patching. They don't bother as much as they used to.
You can not compare a NES game which is limited in scope of game play to a game of today. Why did you even bother to mention this?
I said all other consoles, not just the NES. The PS2 had the ability of network play, for example. Also, I mentioned it because all the arguments you have made thus far also apply to the older consoles. Heck, the Wii is current seems to be able to handle split screen games and has internet capabilities.
You mean like the NES right? You realise games like super mario kart were built with their primary goal being split screen right?
Sure, like the NES. Considering Super Mario Kart was made for the SNES, not NES.
It's not some kind of feature you can just tack on. It effects everything from sound, input, UI and on.
Since modern programming uses multiple levels of abstraction all over the place (partly for convenience, partly for portability), it is getting a lot closer to being something you can "just tack on".
Microchips aren't urgent. It doesn't matter if the batch you will send tomorrow arrives in 3 months, as the batch you sent 3 months ago arrives tomorrow (apologies for randomly made up numbers). If you have massively high volume stuff, you just ship it in volume using a pipeline approach.
Again, while horrid, perhaps a better form of population control would be some sort of pandemic that went through and culled the numbers.
Or perhaps birth control. Preventing life is probably more ethical than causing death.
His actions caused a lot of deaths, he faked his own death and has now taken an alias as a philosophical programmer trying to make up for all his wrongs.
On the other hand, you do need signs saying "Hey, Bubba, Don't Dig Here" in many more languages....
Which unfortunately makes it more obvious where critical infrastructure targets are for the terrorists, if you believe in that sort of thing.
And doing split screen would increase development time, debugging and testing on the other consoles too. You failed to explain how it is unique to the current consoles.
Tried it, had I read this post 5 hours into playing it I would have agreed with you. Come hour 6, I lost all interest as it didn't get more interesting as I went along. The whole point of Torchlight was to introduce the back story for the MMO, which is strange because that's the key component that Torchlight lacked. Some lady keeps showing up at checkpoints at regular intervals telling you to go deeper, you go deeper. The quests and maps don't vary enough.
It had great music, good graphics, acceptable gameplay (although higher level spells were lacking) and no story.
The advantage of Diablo was how long Blizz supported it with patches. What are the odds Bethesda will fix any [...] issues [...] before or after release?
None. Fixed that for you too.
And I fixed it again.
You mean the flesh and bone one that's probably decomposed somewhat? I guess it could become a zombified boss to kill or something, but I doubt you would want to stick a rotting leg in your absurdly large pocket next to the 6 plates of armor.
I believe that you are taking the whole "get of my lawn" think a bit too seriously.
They took issue with you claiming "Diablo clone" is wrong and "Roguelike" is correct, not with an attempt to continue what many consider to be a lame meme involving turf.
In case you are new here
Says someone with a higher UID to someone with a lower UID (irony of myself doing the same is noted).
You are taking what I intended to be a comical jab, and use it as the basis for a serious, and non-trivial discussion.
Perhaps you could just voluntarily get off their lawn? ;)
It was implied. If they didn't want to imply the "massively" component, they could have just said mulitplayer or MO or something equivalent (or just leave it as co-op).
Seriously is it that hard? I've dealt with splitscreen multiplayer since the NES so why is it so hard to find now?
Could be because split screen uses more resources like they state in the article or because split screen needs more development time, etc.
Explain how your point is valid for the PS3 and 360 but didn't apply to the NES and other consoles.