want to share files? host your own server - thats how we used to do it back in the day.
i also have projects i work on where i need to share "legal" files (artwork, music et al) for various things - why would i want to upload it to a public service where anyone can access this stuff? with my own ftp server, heck, can even expose it via http with htaccess - my clients can upload/download files as they need.
it is the pirates (stealing music, videos) who use these public services.. maybe we will see a few more of these sites drop, it is where all of our software that we have written ends up for kiddies to pirate. i say this is a step in the right direction. for p2p file sharing, bittorrent is always the way to go.. but, depends on the community as another poster has said.
the issue is when a developer focuses on one platform; utilizes special functionality and then says "oh.. i need to support that platform to". this is purely a design problem; not an industry problem. if you know, you need to support multiple platforms - one key word.. ABSTRACTION. separate platform code from business logic. that way; when you need to add a new platform, you have a small layer of abstraction to implement appropriately.. games are easier, as UI isn't an issue - but you can do the same with business applications (hint: standards, HTML5 et al).
i've been doing cross platform development for years, always laugh at comments on how difficult it is. if developers were not so trigger happy to get coding; they could simply design/architect their solutions better and there wouldn't be a problem at all. the great thing about my games/apps - i can add a new platform without modifying a single line of the application code itself. implement abstraction layer - select target.. compile.
dealing with complexities of distribution models on different platforms (ios, mac, windows, linux, webos, playbook, windows phone 7).. thats a PITA.
it was only the "enyo" and "web friendly" development environments that used webkit. you can write very powerful applications using native code (SDL, open GL) - which under the hood utilized CodeSourcery Toolchain—Sourcery G++ Lite for ARM. in fact, a lot of our games ran better on webos than on ios due to apple's insane requirement that there was no framebuffer available for graphics and you have to do everything via open GL.
i think these "insiders" do not know what they are talking about. but the fact that there are no more devices being made - i guess the whole discussion becomes mute.. relying on $99 fire-sales to get users to develop against does not work in my books.
but seriously; these code-jamming sessions are cool and all but doing so typically means cutting corners and not really having enough time to do all the appropriate testing and validation.. i mean these are great for prototyping. it is like having 10 minute abs and then someone releases a new method for 9 minutes. w00t.
i am the type that leaves everything in the Inbox and search for what i need - but when i was issued a company laptop with Office 2007 installed; Outlook just sucked at searching the Inbox. upgrading to a Mac OSX laptop with Office 2011, everything just got a lot better - meaning searching the "Inbox" is now feasible again:) i think it really depends on the mail client that is used (or, forced onto you - in a corporate environment).. i've always found searching the Inbox in gmail to be very efficient. in some cases tho; breaking your "massive" inbox into smaller project inboxes, categorizing them at least one level makes sense - you just need to remember your logical separation before diving into a search; worst case, you can search recursively as well.
any plans to ban it germany, file a motion in berlin? these patent wars are getting stupid - why not just share the knowledge and build an awesome product instead of all this crazy fighting over who has the biggest penis.
guru "unix" command line users know pretty much exactly what they are doing and mostly escape extend their commands and type like there is no tomorrow - you would have to play back these videos in slow motion to really learn from them, command typed, enter pressed, pages of stdout scroll by. nice reference point for learners. the only way to truly learn unix commands and get comfortable with command line tools is to avoid the UI completely. try doing stuff from your tty terminals and disable x11:) learn to do word processing with latex, telnet into your routers to configure them. if your not up for doing that, forget about using the command line tools. back in the early 90's, we couldn't afford RAM to even start x11:) i personally use cygwin on windows and terminal on macosx for as much as i can.. never know when you need those command line skills again
CEO? where was that justification taken from? the article specifically talks about 525 people - which are within the hardware area of the company (logical), when i see some developer relations guys and the OS developers get fired; then i'll believe where things are going. since they do not make hardware anymore; it is only natural these are the hardware guys being flushed out.
as a developer; it is going to be a royal pain in the rear to recompile our apps to support another processor architecture; unless of course they go down the emulation route; but using x86 and emulating ARM is going to require a lot of processing power. if intel was to build ARM chips; sure - but typically we associated x86 with intel. apple has experience with this with the transition from PPC to x86 for the mac osx environment; i am sure they'll keep that in mind for iOS developers as well. i would only see recompilation as feasible - emulating ARM wouldn't make sense.
yes - the issue with video tools is more the optimization and performance of the codecs, they are typically built for desktop environments and do not compile well for mobile platforms. just search slashdot for my 36 hour porting effort of lemmings to many platforms.. that was a complete game, not a mere codec.. the codec job is much easier. it is very trivial if you know what you are doing. google even made it easier recently:
http://developer.android.com/sdk/ndk/index.html
>> Android NDK, Revision 4b (June 2010) Adds support for Android 2.2, including a new stable API for accessing the pixel buffers of Bitmap objects from native code.
how about doing some RTFM and then bitching about how difficult things are.. it is typical people comment before doing any form of research - this stuff is really simple. it didn't even deserve a slashdot mention in the first place.
the NDK has been available for years - what has taken them so long to find this out? create a texture, pass a pointer to it and compile the codec natively. nit more than a one-day job if you know what you are doing. the issue is more about the optimizations of the codecs, not the language barrier.
It doesn't give you the right to basically rip them off.
it wasn't a rip off - i was so close to even open sourcing the whole thing, the reason why i did not is because it uses a common library which i own to cross-build on multiple platforms. in fact, we even have a linux version, i just never booted a VM with linux during this 36 hour period, otherwise, it would be FIVE platforms. we did this as a dedication to the game, not to profit from it we were going to release it for free, no adverts, no catches, 100% free, as in beer. it is a tribute because SCEE never seems to license content outside of their own hardware, as we have seen in the past - 10 years ago we chased down who owned it, with no avail. it has gotten complex. since then, the only versions have been for the PSP or PS3. nice to see them locking the IP to their own platforms, rather than even being open about discussing other platforms (which technically compete with their own). who's best interest do they have?
some commenters here simply blurt out comments without thinking at times, and it has made slashdot degrade a lot over the last 10 years - it is a sad pity actually.
every lemmings clone that has used the original files or name and left alone every clone that has not.
we have NOT used the original files, in fact - if you read the blog, you will see how we actually generated the levels using bitmaps and text files for configuration, all built without the original lemmings DAT files (yes, you can use them - but we did not). right now, it comes down to the Lemmings trademark with video games and the look for feel issue.
nice to get slashdotted twice in a week - the website still seems to be up this time around.
since i am on vacation (in egypt) for two weeks - i had to simply withdraw the submission and downloads from the application catalogs and own website, since sony gave a 48 hour window, i can deal with it in more detail when i am back from vacation. as for the intellectual property, no original code was uses (in fact, the palm os version was my own implementation) the only thing that is definitely "used" is the name (Lemmings) and the original EGA graphics from the game. even the levels are redesigned in the event that they are not workable with one player mode and the limitations of the palm os platform
IANAL - but since no original files are used, in fact everything is re-created without reference to the original source code, the only infringing rights here are the use of the name "Lemmings". there have been a number of copyright cases dealing with the look and feel - so it can go either way, intellectual property rights come down to if a jury believes there is confusion between the original and the remake.
i will try to open discussions with SCEE (Sony Entertainment) about getting an official license for the game, in fact, we were looking for the original license holders back in 2001 when we did the palm os versions - but it was in flux between Take Two Interactive, Sony and no-one knew their ass from a hole in the ground. the good news is now SCEE are claiming ownership, so we can now talk to them - and we have proof of concepts made, so if they play nice, this title will officially come to these platforms, if not - then you can start saying how evil they are.
Then how do you target BlackBerry and Android, both of which use Java?
android - NDK (native development kit) the library portion i provide is actually still Java; but with JNI calls to the real meat of the code.
Or how do you justify to your boss the lost sales from not targeting these platforms?
i support android - i have demo versions in place - so, thats not an issue. as for justifying it to my boss? i am my own boss - justified. but you do raise a valid point.
is it me - or are some of the slashdot moderators total idiots? either apple or microsoft fan boys. when i was your age you were probably still in diapers. obviously they miss the point. oh well.
If you are writing different libraries for each platform -- that's not 100% code re-use
sure it is. if you use libc - is that code re-use? i have done a library for a generic platform for developing on top of. it is a library; that as a developer you dont have to write - you just use it.. just like openGL, libc, mathlib et al
You're not "just distributing" the same binary for each platform.
unless there is a universal "thick binary" standard; you are going to have to ship different binaries. thats how it is.
What are you using for graphics, sounds, storage, etc. on each platform?
graphics - you can generically define graphic sets based on DPI. scaling, layout design. it is not difficult to play with different resolutions. as for audio; worst case; you have PCM audio.
You're doing this without a bunch of #ifdef's?
yes!
How are you accounting for different screen resolutions, graphics hardware, touch capabilities, and other hardware difference?
very good design.:)
but seriously - a good architect design can allow you to dynamically detect, load and work with functionalities across platforms. abstraction is dangerous - as it typically defines a common denominator. like web technologies are being dynamic in the way they work (ref: RESTful) - you can do the same with programming.
i've been working with mobile platforms for 10+ years and i've played with almost every platform out there. i avoid.NET and Java like the plague for mobile applications - the end results are very slow and just doing deliver what i want from a programming environment.. sure, i need to do more effort - but the results are better.
this is what i do for a living as well. if you want to discuss more offline - you can reach me via the contact me section on my website.
i've been writing code across many platforms with 100% code reuse - more importantly, not using a runtime - all my applications are native. just write a few basic entry points; put the platform specific points in a library and then all your applications link against this. you then end up with native binaries for each platform - just distribute. this is not news - most developers have been able to do this for years (including myself). i can build applications for windows, linux, macosx, iphone, windows mobile, symbian series 60/uiq, palmos, moblin, maemo et al by doing this and i've been doing it since 2003.
i think this information is out of context. it is very unlikely developers will be abandoning platforms like the wii, ps3 et al - they will most likely be looking to use the iphone as a complimentary development platform more than anything else. there is just as much business everywhere; and if everyone was moving to the iphone - i would probably get out of it:) i was there from the beginning as a hobbyist - and it already is getting flooded and saturated.. it is a pity honestly.
10.3 was powerpc specific - and you can see from the screen shot that they are using pearpc - a powerpc emulation engine.
what would be much more interesting is to port iphone os to the n900 - it has an ARM cpu and should be able to run about the same speed as the iphone itself - that is more a challenge. putting msdos on symbian, android, iphone os, windows mobile is simply a matter of porting dosbox or so; when will someone take on the true challenge:) take a recovery image and flash it to an ARM device with similar specs.. should be doable:)
what do you think the JVM is written in? JIT support is NOT available on mobile implementations typically . your confusing the advances in desktop Java vs the mobile versions.
C does not require any virtual memory / exception handling.. and most C++ support requires you disable it anyhow. if you screw up your memory access; of course it'll reset - thats something you'll learn as a mobile developer.
- palm os (68k) - palm os (arm) - tapwave zodiac (drm specific) - windows mobile / pocket pc - vtech helio - symbian s60 - symbian s60 (3rd+) (binary break) - symbian uiq, - ebookman - gizmondo (gaming handheld) - sony psp (homebrew) - windows desktop (95+) - linux - moblin (drm specific) - mac osx - iphone / ipod touch - android (in beta now)
the platform is just a target when we compile:)
for android; we have a thin Dalvik application that gives us a window; from there - we have a native call using the NDK to render the framebuffer that we show as a window within the application itself.
you would NOT build different versions for droid, htc hero, G1 etc.. as long as they use the same CPU architecture (ARM in this case); the applications will work across the various devices.
depending on the phase - we have the various platforms running at the latest version; the key point is our applications use a common source code base - so, adding/removing a platform does not require any changes to the application itself.
if you have further questions - please don't hesitate to contact me. we've been building this layer for over 8 years now - and we have seen platforms come and go! our framework has been used commercially; but as a platform - you don't see it when it is being used.
Slashdot Mirror
want to share files? host your own server - thats how we used to do it back in the day.
i also have projects i work on where i need to share "legal" files (artwork, music et al) for various things - why would i want to upload it to a public service where anyone can access this stuff? with my own ftp server, heck, can even expose it via http with htaccess - my clients can upload/download files as they need.
it is the pirates (stealing music, videos) who use these public services.. maybe we will see a few more of these sites drop, it is where all of our software that we have written ends up for kiddies to pirate. i say this is a step in the right direction. for p2p file sharing, bittorrent is always the way to go.. but, depends on the community as another poster has said.
cross-platform development is not hard.
the issue is when a developer focuses on one platform; utilizes special functionality and then says "oh.. i need to support that platform to". this is purely a design problem; not an industry problem. if you know, you need to support multiple platforms - one key word.. ABSTRACTION. separate platform code from business logic. that way; when you need to add a new platform, you have a small layer of abstraction to implement appropriately.. games are easier, as UI isn't an issue - but you can do the same with business applications (hint: standards, HTML5 et al).
i've been doing cross platform development for years, always laugh at comments on how difficult it is. if developers were not so trigger happy to get coding; they could simply design/architect their solutions better and there wouldn't be a problem at all. the great thing about my games/apps - i can add a new platform without modifying a single line of the application code itself. implement abstraction layer - select target.. compile.
dealing with complexities of distribution models on different platforms (ios, mac, windows, linux, webos, playbook, windows phone 7).. thats a PITA.
when you download the SDK, you get the PDK included. this was only recently the way however - with 3.0 SDK.
um.. PDK (plugin "native" development kit)?
https://developer.palm.com/content/resources/develop/sdk_pdk_download.html
it was only the "enyo" and "web friendly" development environments that used webkit. you can write very powerful applications using native code (SDL, open GL) - which under the hood utilized CodeSourcery Toolchain—Sourcery G++ Lite for ARM. in fact, a lot of our games ran better on webos than on ios due to apple's insane requirement that there was no framebuffer available for graphics and you have to do everything via open GL.
i think these "insiders" do not know what they are talking about. but the fact that there are no more devices being made - i guess the whole discussion becomes mute.. relying on $99 fire-sales to get users to develop against does not work in my books.
http://games.slashdot.org/story/10/06/28/0253226/Porting-Lemmings-In-36-Hours
but seriously; these code-jamming sessions are cool and all but doing so typically means cutting corners and not really having enough time to do all the appropriate testing and validation.. i mean these are great for prototyping. it is like having 10 minute abs and then someone releases a new method for 9 minutes. w00t.
i am the type that leaves everything in the Inbox and search for what i need - but when i was issued a company laptop with Office 2007 installed; Outlook just sucked at searching the Inbox. upgrading to a Mac OSX laptop with Office 2011, everything just got a lot better - meaning searching the "Inbox" is now feasible again :) i think it really depends on the mail client that is used (or, forced onto you - in a corporate environment).. i've always found searching the Inbox in gmail to be very efficient. in some cases tho; breaking your "massive" inbox into smaller project inboxes, categorizing them at least one level makes sense - you just need to remember your logical separation before diving into a search; worst case, you can search recursively as well.
any plans to ban it germany, file a motion in berlin? these patent wars are getting stupid - why not just share the knowledge and build an awesome product instead of all this crazy fighting over who has the biggest penis.
guru "unix" command line users know pretty much exactly what they are doing and mostly escape extend their commands and type like there is no tomorrow - you would have to play back these videos in slow motion to really learn from them, command typed, enter pressed, pages of stdout scroll by. nice reference point for learners. the only way to truly learn unix commands and get comfortable with command line tools is to avoid the UI completely. try doing stuff from your tty terminals and disable x11 :) learn to do word processing with latex, telnet into your routers to configure them. if your not up for doing that, forget about using the command line tools. back in the early 90's, we couldn't afford RAM to even start x11 :) i personally use cygwin on windows and terminal on macosx for as much as i can.. never know when you need those command line skills again
CEO? where was that justification taken from?
the article specifically talks about 525 people - which are within the hardware area of the company (logical), when i see some developer relations guys and the OS developers get fired; then i'll believe where things are going. since they do not make hardware anymore; it is only natural these are the hardware guys being flushed out.
as a developer; it is going to be a royal pain in the rear to recompile our apps to support another processor architecture; unless of course they go down the emulation route; but using x86 and emulating ARM is going to require a lot of processing power. if intel was to build ARM chips; sure - but typically we associated x86 with intel. apple has experience with this with the transition from PPC to x86 for the mac osx environment; i am sure they'll keep that in mind for iOS developers as well. i would only see recompilation as feasible - emulating ARM wouldn't make sense.
http://en.wikipedia.org/wiki/World_population
russia and china make up 21.5% of the worlds population - i am sure the 90% result will skew a lot more with these included.
yes - the issue with video tools is more the optimization and performance of the codecs, they are typically built for desktop environments and do not compile well for mobile platforms. just search slashdot for my 36 hour porting effort of lemmings to many platforms.. that was a complete game, not a mere codec.. the codec job is much easier. it is very trivial if you know what you are doing. google even made it easier recently:
http://developer.android.com/sdk/ndk/index.html
>> Android NDK, Revision 4b (June 2010)
Adds support for Android 2.2, including a new stable API for accessing the pixel buffers of Bitmap objects from native code.
how about doing some RTFM and then bitching about how difficult things are.. it is typical people comment before doing any form of research - this stuff is really simple. it didn't even deserve a slashdot mention in the first place.
the NDK has been available for years - what has taken them so long to find this out? create a texture, pass a pointer to it and compile the codec natively. nit more than a one-day job if you know what you are doing. the issue is more about the optimizations of the codecs, not the language barrier.
they got 20 seats
http://www.val.se/val/val2010/valnatt/R/rike/index.html
It doesn't give you the right to basically rip them off.
it wasn't a rip off - i was so close to even open sourcing the whole thing, the reason why i did not is because it uses a common library which i own to cross-build on multiple platforms. in fact, we even have a linux version, i just never booted a VM with linux during this 36 hour period, otherwise, it would be FIVE platforms. we did this as a dedication to the game, not to profit from it we were going to release it for free, no adverts, no catches, 100% free, as in beer. it is a tribute because SCEE never seems to license content outside of their own hardware, as we have seen in the past - 10 years ago we chased down who owned it, with no avail. it has gotten complex. since then, the only versions have been for the PSP or PS3. nice to see them locking the IP to their own platforms, rather than even being open about discussing other platforms (which technically compete with their own). who's best interest do they have?
some commenters here simply blurt out comments without thinking at times, and it has made slashdot degrade a lot over the last 10 years - it is a sad pity actually.
every lemmings clone that has used the original files or name and left alone every clone that has not.
we have NOT used the original files, in fact - if you read the blog, you will see how we actually generated the levels using bitmaps and text files for configuration, all built without the original lemmings DAT files (yes, you can use them - but we did not). right now, it comes down to the Lemmings trademark with video games and the look for feel issue.
nice to get slashdotted twice in a week - the website still seems to be up this time around.
since i am on vacation (in egypt) for two weeks - i had to simply withdraw the submission and downloads from the application catalogs and own website, since sony gave a 48 hour window, i can deal with it in more detail when i am back from vacation. as for the intellectual property, no original code was uses (in fact, the palm os version was my own implementation) the only thing that is definitely "used" is the name (Lemmings) and the original EGA graphics from the game. even the levels are redesigned in the event that they are not workable with one player mode and the limitations of the palm os platform
IANAL - but since no original files are used, in fact everything is re-created without reference to the original source code, the only infringing rights here are the use of the name "Lemmings". there have been a number of copyright cases dealing with the look and feel - so it can go either way, intellectual property rights come down to if a jury believes there is confusion between the original and the remake.
i will try to open discussions with SCEE (Sony Entertainment) about getting an official license for the game, in fact, we were looking for the original license holders back in 2001 when we did the palm os versions - but it was in flux between Take Two Interactive, Sony and no-one knew their ass from a hole in the ground. the good news is now SCEE are claiming ownership, so we can now talk to them - and we have proof of concepts made, so if they play nice, this title will officially come to these platforms, if not - then you can start saying how evil they are.
lets see how the discussions go!
Then how do you target BlackBerry and Android, both of which use Java?
android - NDK (native development kit)
the library portion i provide is actually still Java; but with JNI calls to the real meat of the code.
Or how do you justify to your boss the lost sales from not targeting these platforms?
i support android - i have demo versions in place - so, thats not an issue. as for justifying it to my boss? i am my own boss - justified. but you do raise a valid point.
90% shared code? so what? (Score:-1, Troll)
is it me - or are some of the slashdot moderators total idiots? either apple or microsoft fan boys. when i was your age you were probably still in diapers. obviously they miss the point. oh well.
If you are writing different libraries for each platform -- that's not 100% code re-use
sure it is. if you use libc - is that code re-use? i have done a library for a generic platform for developing on top of. it is a library; that as a developer you dont have to write - you just use it.. just like openGL, libc, mathlib et al
You're not "just distributing" the same binary for each platform.
unless there is a universal "thick binary" standard; you are going to have to ship different binaries. thats how it is.
What are you using for graphics, sounds, storage, etc. on each platform?
graphics - you can generically define graphic sets based on DPI. scaling, layout design. it is not difficult to play with different resolutions. as for audio; worst case; you have PCM audio.
You're doing this without a bunch of #ifdef's?
yes!
How are you accounting for different screen resolutions, graphics hardware, touch capabilities, and other hardware difference?
very good design. :)
but seriously - a good architect design can allow you to dynamically detect, load and work with functionalities across platforms. abstraction is dangerous - as it typically defines a common denominator. like web technologies are being dynamic in the way they work (ref: RESTful) - you can do the same with programming.
i've been working with mobile platforms for 10+ years and i've played with almost every platform out there. i avoid .NET and Java like the plague for mobile applications - the end results are very slow and just doing deliver what i want from a programming environment.. sure, i need to do more effort - but the results are better.
this is what i do for a living as well. if you want to discuss more offline - you can reach me via the contact me section on my website.
i've been writing code across many platforms with 100% code reuse - more importantly, not using a runtime - all my applications are native. just write a few basic entry points; put the platform specific points in a library and then all your applications link against this. you then end up with native binaries for each platform - just distribute. this is not news - most developers have been able to do this for years (including myself). i can build applications for windows, linux, macosx, iphone, windows mobile, symbian series 60/uiq, palmos, moblin, maemo et al by doing this and i've been doing it since 2003.
i think this information is out of context. it is very unlikely developers will be abandoning platforms like the wii, ps3 et al - they will most likely be looking to use the iphone as a complimentary development platform more than anything else. there is just as much business everywhere; and if everyone was moving to the iphone - i would probably get out of it :) i was there from the beginning as a hobbyist - and it already is getting flooded and saturated.. it is a pity honestly.
10.3 was powerpc specific - and you can see from the screen shot that they are using pearpc - a powerpc emulation engine.
what would be much more interesting is to port iphone os to the n900 - it has an ARM cpu and should be able to run about the same speed as the iphone itself - that is more a challenge. putting msdos on symbian, android, iphone os, windows mobile is simply a matter of porting dosbox or so; when will someone take on the true challenge :) take a recovery image and flash it to an ARM device with similar specs.. should be doable :)
wow.. you surely must not get it.
what do you think the JVM is written in? JIT support is NOT available on mobile implementations typically . your confusing the advances in desktop Java vs the mobile versions.
C does not require any virtual memory / exception handling.. and most C++ support requires you disable it anyhow. if you screw up your memory access; of course it'll reset - thats something you'll learn as a mobile developer.
actually; the platform i'm built has layers for:
- palm os (68k)
- palm os (arm)
- tapwave zodiac (drm specific)
- windows mobile / pocket pc
- vtech helio
- symbian s60
- symbian s60 (3rd+) (binary break)
- symbian uiq,
- ebookman
- gizmondo (gaming handheld)
- sony psp (homebrew)
- windows desktop (95+)
- linux
- moblin (drm specific)
- mac osx
- iphone / ipod touch
- android (in beta now)
the platform is just a target when we compile :)
for android; we have a thin Dalvik application that gives us a window; from there - we have a native call using the NDK to render the framebuffer that we show as a window within the application itself.
you would NOT build different versions for droid, htc hero, G1 etc.. as long as they use the same CPU architecture (ARM in this case); the applications will work across the various devices.
depending on the phase - we have the various platforms running at the latest version; the key point is our applications use a common source code base - so, adding/removing a platform does not require any changes to the application itself.
if you have further questions - please don't hesitate to contact me. we've been building this layer for over 8 years now - and we have seen platforms come and go! our framework has been used commercially; but as a platform - you don't see it when it is being used.