Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Csonicgo

Porting source ports to Android 4.0

Recommended Posts

Maes said:

It's not unusual to be able to make a more lightweight version of e.g. a Stack or ArrayList class than the built-in one, even for a novice programmer, especially if limited to a single data type. What such re-implementations often "lose" are some frills like thread safety, generics (but not always), implementation of some exotic interfaces, serialization, etc. and of course having to prove from the ground up that they are correct.

While this may be true, one thing most other languages don't have to put up with is binary bloat from using their standard templates. In Java generics are basically a way of having the compiler handle Object casts for you and don't really exist at run time. I'm not familiar with all the implementation details of ArrayList, but I can't imagine where it would perform significantly poorly from another implementation. I can see making specialized containers for primitives, but that's about it.

C++ templates generate code at compile time, which has many benefits, but it does mean that heavy template usage (as seen in the STL) can bring the binary size up dramatically. I'm sure having all that code duplication (and I reiterate that it usually isn't a small file size difference) doesn't help with CPU caching, but I'm not an expert here.

Share this post


Link to post
Blzut3 said:

C++ templates generate code at compile time, which has many benefits, but it does mean that heavy template usage (as seen in the STL) can bring the binary size up dramatically. I'm sure having all that code duplication (and I reiterate that it usually isn't a small file size difference) doesn't help with CPU caching, but I'm not an expert here.



The binary bloat itself is probably not the worst thing here. If there's dead code it just won't be used.


But with STL it's more like it even creates larger code for the same operations that are performed by significantly less code in more lightweight packages - and in the end nobody will be able to convince me that a bloated class performs better than a more streamlined one.

The thing with STL is that the code is so intermingled and obfuscated that it's close to impossible to see how it all works together and what pieces of code are actually executed to perform a certain operation. I really don't like working with such code. It may do horrible things you aren't even aware of (like the copy-by-value stuff Quasar mentioned earlier.)

Share this post


Link to post
Blzut3 said:

When I converted ECWolf from std::vector, etc to ZDoom's containers. The size of the binary went from several MB to less than a MB IIRC. The std containers are quite bloated.

So I was better off when I didn't know about STL, and kept reinventing things like "List" data structures? Damnit, and thanks for the tip :-/

Does STL usage have a large RAM footprint? Maybe that's more important to consider (on hard-disk personal computers)...

Share this post


Link to post

The vast majority of the time, you don't need to roll your own data structures at all. Unless you are working on truly "hot path" code like that in the guts of say a software renderer, there is little point in shunning the standard library.

Share this post


Link to post

It depends on what you want to do with it.
Sometimes you just can't afford to let implementation differences to get in the way, so in Doom terms STL may be unsuitable when it comes to demo sync issues. You just can't risk to have different algorithms to produce results that aren't guaranteed to be 100% identical in all cases.

Anyway, regarding std::vector and ZDoom's TArray, since I have both I tend to use the one that's more to my liking and that's clearly the ZDoom version.

Share this post


Link to post

Naturally it does depend on how you use them, however, I would say that if your not using the STL for some task is because of the potential for implementation details changing the outcome then you haven't dutifully considered the solution in the first place; i.e., you've failed to encapsulate and then define it unambiguously. Edit: But then one could say that by implementing your own structures that ensure whatever rule(s) your solution demands then you have done just that. Personally though, I only consider rolling my own data structures when absolutely necessary.

Share this post


Link to post

The fastest path today would probably be firing a PC emulator on it, hoping that you get enough emulated power to match a Pentium I @ 200 MHz running Windows 98 (lowest specs I ever ran ZDoom "playably" with vanilla maps), starting ZDoom (software mode only!) at a low resolution (640 x 400 as an absolute tops) and hope for the best ;-)

This might be barely feasible on a GHz class CPU. Don't expect the batteries to last too long, though, and I have no idea how the controls would map.

Share this post


Link to post

I have a samsung galaxy s2, so power is not a problem. I also tried to run ZDoom using adosbox but that gave me an error. I mostly want to install it so that I can play multiplayer (that is one of the reasons I wouldnt want to run it through a windows installation) and zdoom supports more maps. GZdoom would be even better... I think that runnng ZDoom on the android operating stem is a very worthy persuit in the name of DOOM science, heh. But not an easy one :/

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×