Forums » General
http://gte.philtopia.com/activity/
^ I just posted some pictures of VO running on my old G3 PowerMac that I had picked up from my Mom's last week....
I managed to get 2 pk's in b8 as well..lol
^ I just posted some pictures of VO running on my old G3 PowerMac that I had picked up from my Mom's last week....
I managed to get 2 pk's in b8 as well..lol
Haha. Glad you got it in now. We're dropping PPC pretty soon. Make that decision a few months ago, just haven't had a chance to act on it yet.
ok when you get steam and iPhone going you can cut ppc without me complaining about it even though ill probably never use it again (but i have steam and an iPhone)
Inc, any thoughts on OpenRISC? I don't imagine it will reach the level of adoption anytime soon to justify development efforts, but I'm interested in your thoughts on it as a developer as it appears to be trying to capture some of the ARM market, and is completely open source.
Spence, why would Steam be necessary to drop PPC support? Anything that Steam runs on would accept a manual VO installation.
Spence, why would Steam be necessary to drop PPC support? Anything that Steam runs on would accept a manual VO installation.
they can't remove things without adding something
it's the law!
it's the law!
If my PowerBook G4 wasn't in storage, we could have a PPC duel. :D
We're dropping PPC pretty soon. Make that decision a few months ago, just haven't had a chance to act on it yet.
Aww, I still fire up my dual G5 tower just to hear the jet-engine fan while I fly.
Aww, I still fire up my dual G5 tower just to hear the jet-engine fan while I fly.
Inc, any thoughts on OpenRISC? I don't imagine it will reach the level of adoption anytime soon to justify development efforts, but I'm interested in your thoughts on it as a developer as it appears to be trying to capture some of the ARM market, and is completely open source.
I don't have a lot of familiarity. It sounds like a neat project, their own SIMD instruction set and so on, and very cool that it's open-source.
But as you say, it would have to reach a fairly high market density before it would offset our on-going maintenance costs to support it on a weekly-release kind of basis. From Wikipedia, it sounds very early, mostly FPGA usage and hardly any ASICs. I mean, we didn't support Intel on Android for like two years, because it wasn't worth the cost yet. We still don't support MIPS on Android, and there are quite a few devices out there (albeit mostly in China and other lower cost markets).
We have a lot of headache and overhead that comes from the sheer number of platforms we support, adding more isn't a priority unless there's a big reason for it (like real market share, getting directly paid to support it by the platform maker, that kind of thing).
On the flipside, I can actually see OpenRISC being way more useful on the enterprise (server) side. If that drops the per-chip cost a bit further to make OpenRISC based cloud servers more cost effective, that could be interesting. There are a lot of people pursuing ARM-in-the-cloud solutions, most prominently Qualcomm at the moment. It makes a lot of sense for a lot of cases.. extremely low idle power usage, great thermal efficiency, and "enough" power for smaller or parallel-scalable cases. We could run most of our game off of ARM, for instance (albeit, with a different density of sectors-per-CPU than we currently use).
I don't have a lot of familiarity. It sounds like a neat project, their own SIMD instruction set and so on, and very cool that it's open-source.
But as you say, it would have to reach a fairly high market density before it would offset our on-going maintenance costs to support it on a weekly-release kind of basis. From Wikipedia, it sounds very early, mostly FPGA usage and hardly any ASICs. I mean, we didn't support Intel on Android for like two years, because it wasn't worth the cost yet. We still don't support MIPS on Android, and there are quite a few devices out there (albeit mostly in China and other lower cost markets).
We have a lot of headache and overhead that comes from the sheer number of platforms we support, adding more isn't a priority unless there's a big reason for it (like real market share, getting directly paid to support it by the platform maker, that kind of thing).
On the flipside, I can actually see OpenRISC being way more useful on the enterprise (server) side. If that drops the per-chip cost a bit further to make OpenRISC based cloud servers more cost effective, that could be interesting. There are a lot of people pursuing ARM-in-the-cloud solutions, most prominently Qualcomm at the moment. It makes a lot of sense for a lot of cases.. extremely low idle power usage, great thermal efficiency, and "enough" power for smaller or parallel-scalable cases. We could run most of our game off of ARM, for instance (albeit, with a different density of sectors-per-CPU than we currently use).
damnit! i wanted to run VO on my g4/g5 too one time, where can i get the ppc version?
while we are already discussing ARM, could we have a OpenGL ES variant for linux? i dont want to run a hacky/funky android on all my arm devices just so i can use VO...
while we are already discussing ARM, could we have a OpenGL ES variant for linux? i dont want to run a hacky/funky android on all my arm devices just so i can use VO...
The current vendetta download for OSX is universal. So just download it and voila. As for OpenGL ES on ARM Linux, I have been asking for that since the Open Pandora was released and the Pyra was announced. I would not hold your breath.
so there is no ppc variant for linux, just OSX? not sure if my g4 or g5 still has OSX on it... guess i'll have to put OSX on it too
lol ppc linux, now you're just being a greedy jerk
if they did program in a sane way, its just compiling for another architecture.
@Inc: have you tried this? if so could i get a testing release to play around with? also the same for ARM? i can translate OpenGL ES to OpenGL via wrapping, but there is no VO binary... As you'd use OpenGL for ppc anyway, there shouldnt be a big issue. Tough, endianess may bite you in case of non portable code.
Im definitely interested in trying to get it run, even if i have to use the wrapper... But emulating a x86_64 under ARM to make VO run and then also translate OpenGL to OpenGL ES is way too much overhead. (yes i've done this before, but with win apps + wine! call me crazy if you have to. playing AoE2TC on those devices is just fun.)
@Inc: have you tried this? if so could i get a testing release to play around with? also the same for ARM? i can translate OpenGL ES to OpenGL via wrapping, but there is no VO binary... As you'd use OpenGL for ppc anyway, there shouldnt be a big issue. Tough, endianess may bite you in case of non portable code.
Im definitely interested in trying to get it run, even if i have to use the wrapper... But emulating a x86_64 under ARM to make VO run and then also translate OpenGL to OpenGL ES is way too much overhead. (yes i've done this before, but with win apps + wine! call me crazy if you have to. playing AoE2TC on those devices is just fun.)
+1 Xeha
I've just played with a G5 VO. was fun, i'll definitely do it again in case the support will be continued :)
If you're optimizing for performance, then unfortunately you can't just program it in a sane way.
@Inc: have you tried this? if so could i get a testing release to play around with? also the same for ARM? i can translate OpenGL ES to OpenGL via wrapping, but there is no VO binary... As you'd use OpenGL for ppc anyway, there shouldnt be a big issue. Tough, endianess may bite you in case of non portable code.
Our codebase is highly portable, but the reality is there are hidden, unexpected issues that crop up on any new platform. Adding x86 support to our existing Android build for ARM was "interesting" that way. It should have been simpler than it was.
If you're looking to run an ES build on an ARM-native device, I would probably look at writing a wrapper for Android apps in general. We're almost entirely native, so there's only the minimum amount of java platform stuff for setup and application housekeeping. All the ES, sound, input and network calls should be native (either Android-native NDK or standard unix sockets or whatever).
Anyway, our dev-time is completely saturated right now, and for the foreseeable future.. so rolling specialty one-off builds for people (which may quickly stop being usable as we make protocol changes), is not something that we're likely to burn time on.
Our codebase is highly portable, but the reality is there are hidden, unexpected issues that crop up on any new platform. Adding x86 support to our existing Android build for ARM was "interesting" that way. It should have been simpler than it was.
If you're looking to run an ES build on an ARM-native device, I would probably look at writing a wrapper for Android apps in general. We're almost entirely native, so there's only the minimum amount of java platform stuff for setup and application housekeeping. All the ES, sound, input and network calls should be native (either Android-native NDK or standard unix sockets or whatever).
Anyway, our dev-time is completely saturated right now, and for the foreseeable future.. so rolling specialty one-off builds for people (which may quickly stop being usable as we make protocol changes), is not something that we're likely to burn time on.
A wrapper for Android apps would bring along all of the crap that sucks about Android like no useful mouse input... Kinda defeats the purpose.
Perhaps, but it could work fine with game controllers and flight sticks.
And station bots!!! Xeha do it!!!!!