ios Doom ports are MUCH better than android ones

[printz]

chungy said:

The part where you keep claiming that Apple development is all sunshine and lollipops, while Android development suffers from hardware diversity (Android was *designed* for this; Graf has even given examples where Apple didn't have the foresight to think they would ever change their screen size, and this causes issues)

Well, I've always found Android development to be the most unpleasant. Full of bugs, either just USB app deployment failing, or low-level APIs inexistent/crashy/buggy. Not much fan of the main Java API either, it looks too klunky and it's too easy to throw exceptions. It was always a relief when I had to move back to Windows, iOS, OSX or even GNU/Linux.

[snapshot]

Voros said:

Do plan on making a port of Doom 64 EX (if possible)?

Speaking of that, it would be very cool if someone finally spends some time to Port it , Since most n64 emulators are barely able to run it .

[Voros]

DMGUYDZ64 said:

Speaking of that, it would be very cool if someone finally spends some time to Port it , Since most n64 emulators are barely able to run it .

Well, on my N64oid app on my phone, its just black.
But on Project 64, on windows for me, it run completely fine (unlike Quake)

If anyone were to port Doom 64, it should be Beloko, since his apps are always efficient and precise (for me that is).

[beloko]

Voros said:

Do plan on making a port of Doom 64 EX (if possible)?

Surprised Doom 64 hasn't had it port, although I hear its much more different from Classic Doom.

Oh, and add HacX 2.0 to that list.

Yes it's possible, would need to ask dev if he wouldn't mind first.

[Gez]

Voros said:

Oh, and add HacX 2.0 to that list.

Hacx 2.0 is based on Hacx 1.2 and therefore under the same licensing conditions, which state that use in revenue-raising conditions is strictly forbidden. It is also unfinished; I didn't list it for the same reason I didn't list Blasphemer or Zauberer. Freedoom is unfinished as well, but complete enough to be playable.

[RestlessRodent]

printz said:

Not much fan of the main Java API either.

Android Main API != Java Main API.

Android uses a crippled disfunctional Java-like main library which is stuck in the past. Developing for Android is like developing for Windows 98.

printz said:

too easy to throw exceptions

Exceptions are meant to be easy to be thrown:

throw new RuntimeException("Why!?");

This beats languages without exceptions such as C where failure status is set in errno/a global, the return value, or a pointer argument.

[Graf Zahl]

GhostlyDeath said:

This beats languages without exceptions such as C where failure status is set in errno/a global, the return value, or a pointer argument.

Yeah, right.

I find nothing more annoying than functions that trigger an exception for common errors. I don't know who declared this good style but it's just idiotic.
Anything that FORCES a try/catch block to be put around is broken by design if you ask me. Yes, that means large parts of Java, actually.


I think it should be done by reserving the return value just for the error code and returning anything else through by-value parameters, like, for example, any modern Windows API does (many of the older ones unfortunately don't...)

[RestlessRodent]

Graf Zahl said:

Yeah, right.

I find nothing more annoying than functions that trigger an exception for common errors. I don't know who declared this good style but it's just idiotic.
Anything that FORCES a try/catch block to be put around is broken by design if you ask me. Yes, that means large parts of Java, actually.

The forcing of a try/catch block and thrown exceptions in a method is only enforced by the Java compiler not the virtual machine. The Java VM by itself treats all exceptions as unchecked.

So really, you can just modify the compiler and have it treat all checked exceptions as unchecked and nothing will break. However your code would not be compatible with other Java compilers. This is for example how Groovy does things, there are no checked exceptions in Groovy. There is also talk of potentially removing checked exceptions, but if that is done then it would probably be done with annotations such as something such as: @ExceptionsAreUnchecked or similar.

When programming Java, at least when it comes to the standard libraries, the most common checked exception you will encounter is IOException. These are basically read and write operations which can fail. So it being checked is really to make sure that it hopefully is handled because otherwise your data can just be missing due to for example unreliable storage mediums and data transports.

Also, assuming one uses EXTENDED exceptions, they can just change the base class from Exception to RuntimeException and generally nothing should be affected because RuntimeException (which is unchecked) extends Exception.

Graf Zahl said:

I think it should be done by reserving the return value just for the error code and returning anything else through by-value parameters, like, for example, any modern Windows API does (many of the older ones unfortunately don't...)

That can complicate the API prototypes though.

Well, with exceptions you either handle it or the exception propogates up the call stack until it finds a handler or there is none at all. With exceptions it is a kind of a rocket blowing up experience on any kind of exceptional failure.

With Java there are generally three exception types: The exceptional Exception and RuntimeException, and the more fatal Error. Any "Error"s that get caught should just be rethrown because they are potentially just very serious.

But I myself am a fail fast programmer, I find it better having everything blown up rather than having some half crippled state. Of course my programs are not life critical applications.

The main thing C could use though is type safety more like Java/C++.

[Graf Zahl]

GhostlyDeath said:

The forcing of a try/catch block and thrown exceptions in a method is only enforced by the Java compiler not the virtual machine. The Java VM by itself treats all exceptions as unchecked.

In other words, the exceptions are enforced.

GhostlyDeath said:

When programming Java, at least when it comes to the standard libraries, the most common checked exception you will encounter is IOException. These are basically read and write operations which can fail. So it being checked is really to make sure that it hopefully is handled because otherwise your data can just be missing due to for example unreliable storage mediums and data transports.

Exactly! This means that every code that does file access needs to be put in try/catch blocks. Completely annoying. The code just looks fucing ugly due to all the exception handlers.

GhostlyDeath said:

Well, with exceptions you either handle it or the exception propogates up the call stack until it finds a handler or there is none at all. With exceptions it is a kind of a rocket blowing up experience on any kind of exceptional failure.

An exception should be - well - exceptional - that by definition implies that handling on the outermost part of the code should be safe for the common case. But that's not how it's done.
An unhandled IOException would be similar to Doom's I_Error-ing out on the most banal problems. So we are back to square one - they need to be caught for common (as opposed to EXCEPTIONAL) error handling! And that attitude repeats through the entire Java-API.

My personal impression has always been that it had been implemented as a crutch to get around of the lack of by-reference parameters to functions - it's hard to pass both a valid object AND an error code if you can't receive anything through a parameter... (It may have changed by now, or it may not - I haven't followed Java beyond what J2ME supported.)

GhostlyDeath said:

The main thing C could use though is type safety more like Java/C++.

That's why I don't program in C.

[RestlessRodent]

Graf Zahl said:

In other words, the exceptions are enforced.

Exactly! This means that every code that does file access needs to be put in try/catch blocks. Completely annoying. The code just looks fucing ugly due to all the exception handlers.

Well, if you ever decide to do any Java work then Groovy might interest you. You can write normal Java code in it and never have to worry about checked exceptions ever. Although if you do not catch them the code will crash.

Also with Java 7's try-with-resources exception handling gets nicer because you no longer need to juggle lots of nested try/catch/finally blocks to make sure something is closed.

The thing Android needs though is to get in line with standard Java rather than Google running off an doing their own thing.

Graf Zahl said:

An exception should be - well - exceptional - that by definition implies that handling on the outermost part of the code should be safe for the common case. But that's not how it's done.

An unhandled IOException would be similar to Doom's I_Error-ing out on the most banal problems. So we are back to square one - they need to be caught for common (as opposed to EXCEPTIONAL) error handling! And that attitude repeats through the entire Java-API.

At least with an exception system such as in Java/C++, there could be an exception thrown in those cases rather than have it completely fatal.

In ReMooD, the exceptions are mostly for backing out (going back to the title screen or the game lobby). In the end there should not be any exceptional cases for the most part unless your computer is about to die. But if your disk is damaged then you probably should not be playing ReMooD or any other Doom port anyway.

Graf Zahl said:

My personal impression has always been that it had been implemented as a crutch to get around of the lack of by-reference parameters to functions - it's hard to pass both a valid object AND an error code if you can't receive anything through a parameter... (It may have changed by now, or it may not - I haven't followed Java beyond what J2ME supported.)

You can pass an array which the callee can set to a value for usage by the caller, you could do this with all versions of Java. With Java 8 at least you can send a Consumer<Foo> as a parameter which can do stuff in the caller such as set a value or call another method.

[Graf Zahl]

GhostlyDeath said:

Well, if you ever decide to do any Java work then Groovy might interest you. You can write normal Java code in it and never have to worry about checked exceptions ever. Although if you do not catch them the code will crash.

GhostlyDeath said:

At least with an exception system such as in Java/C++, there could be an exception thrown in those cases rather than have it completely fatal.

Apparently you fail to understand my issue here:
Instead of returning a benign failure code if accessing a file fails for whatever reason - a quite common occurence with file IO - this is treated like a serious condition that requires exceptional (pun intended) treatment.

Exceptions are ok if something happens that will utterly disrupt normal program flow, but using it as a standard error reporting mechanism strikes me as complete overkill.

The same happens if some functions get improper data. Again something that should be handled with a benign failure code, not with completely disrupting program flow.

GhostlyDeath said:

In ReMooD, the exceptions are mostly for backing out (going back to the title screen or the game lobby). In the end there should not be any exceptional cases for the most part unless your computer is about to die. But if your disk is damaged then you probably should not be playing ReMooD or any other Doom port anyway.

Agreed. That's how ZDoom uses exceptions as well - but not for reporting common errors on frequently called functions.

[SyntherAugustus]

Gameception is great, but wads with custom textures tend to be rather glitchy for some reason. Not being able to disable randomized sound pitch is also annoying.

I'd really like a ZDoom based port for iOS, but I imagine that's not easy to do.

[Maes]

Graf Zahl said:

Apparently you fail to understand my issue here:
Instead of returning a benign failure code if accessing a file fails for whatever reason - a quite common occurence with file IO - this is treated like a serious condition that requires exceptional (pun intended) treatment.

You know, this reminded me of my first Java textbook (Italian, Bertacca-Guidi from 1998, which covered Java v1.1 while hinting at the -upcoming- v1.2 now and then), which did occasionally have comparisons with C.

Once of them was exactly the way exceptions were handled, and it had a mirror counterexample to your "benign code" approach: it showed a C program laden with if/else blocks after each potentially "exceptional" statement, showing how difficult it was to send one of these error codes back to the caller of a method that caused the exception, if it was more appropriate to handle it there.

The argument in favour of Java was, if I remember correctly, that rather than using obscure numeric return codes to signal specific conditions, a special object was generated, and while the syntax was not necessarily less cluttered, it had however the advantage of being automatically forwarded/cascaded to any caller methods, without having to reserve a specific parameter or add a special interpretation to the return value for the task.

The discretion (in C) to be able to completely ignore error codes, I guess, was viewed as yet another privilege for the hardcore, knows-what-he's-doing type of programmer, which wasn't obviously Java's target group to begin with.

[Graf Zahl]

Maes said:

The argument in favour of Java was, if I remember correctly, that rather than using obscure numeric return codes to signal specific conditions, a special object was generated, and while the syntax was not necessarily less cluttered, it had however the advantage of being automatically forwarded/cascaded to any caller methods, without having to reserve a specific parameter or add a special interpretation to the return value for the task.

Yes, the same bullshit that always gets cited, missing the forest for the trees - namely that many of these errors need to be dealt with close to their cause and not two or three levels down the line.

And then the Java method quickly devolves into a massive mess of try/catch that easily makes the C-method with if/else look beautifully elegant.

It's just another proof that Java has been designed by theorists with little initial thought for practical viability. In an ideal world it should have remained with the theorists.

[beloko]

GZDoom on IOS video:

https://www.youtube.com/watch?v=7TQDQ3qV640

Still a lot to do, but looks like it should work OK.
Some tricky bugs getting it to work involving Classes begin stripped by the linker :)

[SyntherAugustus]

Excitement!

[Voros]

Oh, you actually are developing gzdoom on iOS!

Now the iDevice owners can enjoy Doom to the fullest!

Ecstatic!

[Voros]

Beloko,

Could you port Sonic Robo Blast 2?

I know that it runs on a modified Doom Legacy engine, which isn't GZdoom. But that is fantastic, and isn't Legacy less complicated than GZdoom?

Here's a link to the src code

https://github.com/STJr

[Graf Zahl]

Voros said:

I know that it runs on a modified Doom Legacy engine, which isn't GZdoom. But that is fantastic, and isn't Legacy less complicated than GZdoom?

Not when it comes to the OpenGL code, which is the important thing here, that needs to be changed.

[snapshot]

Graf Zahl said:

Not when it comes to the OpenGL code, which is the important thing here, that needs to be changed.

As far as i know, SRB2 has both OpenGL and software rendering modes (together with the DirectDraw Build), someone already ported it but refused to release it .

[printz]

beloko said:

GZDoom on IOS video:

https://www.youtube.com/watch?v=7TQDQ3qV640

Still a lot to do, but looks like it should work OK.
Some tricky bugs getting it to work involving Classes begin stripped by the linker :)

1) How are you gonna distribute it on the iOS App Store? Will they let you pass?
2) Why not touch the menu directly to click on options? Why still use virtual arrow keys? Desktop ZDoom menu already has a mouse.

[Voros]

DMGUYDZ64 said:

As far as i know, SRB2 has both OpenGL and software rendering modes (together with the DirectDraw Build), someone already ported it but refused to release it .
https://www.youtube.com/watch?v=FA7vyOy09Q8

I know that video, but that's also the problem. Its not available.
Maybe Beloko could take advantage of SRB2, and port it to iOS.
(since it is technically id tech 1 AND beloko seems like an awesome "id tech porter"... and SRB2 is kid friendly!)

[cybdmn]

I am sure, that it will be rejected for copyright reasons.

[Gez]

printz said:

1) How are you gonna distribute it on the iOS App Store? Will they let you pass?

I guess it'll only be for jailbroken users, because Apple is never going to allow a game app where people can load their own content.

[Voros]

Gez said:

I guess it'll only be for jailbroken users, because Apple is never going to allow a game app where people can load their own content.

Gameception?

[beloko]

printz said:

1) How are you gonna distribute it on the iOS App Store? Will they let you pass?
2) Why not touch the menu directly to click on options? Why still use virtual arrow keys? Desktop ZDoom menu already has a mouse.

1. Ya will try the store (If I get time and finish this). As mentioned there is Gameception, and this: https://itunes.apple.com/gb/app/beben-iii/id771105890?mt=8&ign-mpt=uo%3D4 which allows the Quake content.
What ever happens code will be on Github so if they don't allow it someone else can maintain.

2. The menu items are too small, might work on the main menu but options and others are too small.

There is pretty much no way an SRB2 port would be allowed on the app store.

[RestlessRodent]

DMGUYDZ64 said:

[porter of SRB2] refused to release it

Probably because it infringes on the IP of Sonic and they most likely do not want to risk getting sued. Or if they release it, it might just end of being removed anyway due to said IP infringement.

[beloko]

GhostlyDeath said:

Probably because it infringes on the IP of Sonic and they most likely do not want to risk getting sued. Or if they release it, it might just end of being removed anyway due to said IP infringement.

I've not played the game but looking at the screens they just need to change the characters, the name and any infringing graphics then it could be released. But that might miss the point a bit :) Maybe someone could fork a non tradmark and copyright infringing version

[Gez]

They should replace the cartoony sprites by photos of real-world hedgehogs and foxes.

It would be adorable.
http://i.imgur.com/rDAA1sy.webm

[Voros]

beloko said:

I've not played the game but looking at the screens they just need to change the characters, the name and any infringing graphics then it could be released. But that might miss the point a bit :) Maybe someone could fork a non tradmark and copyright infringing version

The graphics can stay, since its not actually ripped from the games (literally I mean), but made by the artists of the team to make it as Sonic like possible.

Plus, the Appstore ain't the the only store for iOS (albeit the official one).

There is this:

http://emu4ios.net

No jailbreak required or any form of hassle. Just visit it on your iDevice and select the one you install. I know it's small, but brilliant (won't find emulators or screen recorders on the Appstore but here).

beloko, have you chosen your IWAD?