Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Abstracting Graphical APIs

  1. #11
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    It is a fascinating subject, I wish you the best of luck with your endeavours
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  2. #12
    Quote Originally Posted by phibermon View Post
    I don't work for Embarcadero, my interests are in sharing knowledge and helping people to create what they want to create using the best possible tools available - not just the ones belonging to a single company.

    I know I spoke mainly of game engines but I'm advising to ignore FMX specifically on abstraction grounds - it's closed source, the user will learn nothing. The general process of API abstraction can be learned from thousands of different sources, studying a closed source API when there's much better and open source examples to study is pointless. After all this site is called pascal *game* development and the user it talking about 3D API's so of course we're talking in the context of 3D game engines. So yes I heard "I want to make a 3D rendering engine" and not "I want to draw buttons on propitiatory platforms". They are two very different goals and the abstractions required are totally different.

    FMX is a poor design even when cited as an example of abstraction so I wonder why you've chosen to mention it at all?

    Frankly, I'm tired of Embarcadero employees recommending unsuitable Delphi features as if they were perfect for games. FMX may make use of 3D API's but don't be tempted to confuse FMX as suitable for game development just because it does. My lawnmower uses petrol, it's not suitable for the race track.

    Recommending somebody dedicate their passion to your product just to shift units is immoral. It is their future in game development, not your advertising platform. The compiler is suitable for game development, the IDE is suitable for development in general and indeed many of the components could be useful as well (for game development, especially if you want to create database driven servers) but FMX out of everything Delphi has to offer is the one thing that definitely is *not* suitable for game development. Not in direct use or as an example of 3D API abstraction.

    Just to be clear : you can use Direct3D and OpenGL in Delphi without FMX. I'm not sure if that's true on the mobile platforms however but there's always Freepascal.
    Hi,

    I read your response at 11pm 30/01 and decided to drop, because, at this moment, it really hurt me.

    this morning, at work, I just see your response again, and I see that you edit it after my read, and you wrote it in a much more diplomatic way.

    --> You make an effort, and I decide too make an effort too, and I'm answering mainly because you ask think on me that is not right : you have the right to defend you opinion, and it should be suffisant.


    To be clear, no, I'm *not* an EMB employees. Sorry Sherlock.


    I'm working in financial stuff in Geneva, mainly in calculation in c language, in hpc/gpu tech, and, sure, a bit of delphi for our GUI.

    So, I'm not working in fpc or lazarus, because we do not need it, simply, even if we have linux in server side, so we need rad for our gui. So we got delphi. So, Yes, I like delphi for years and I really believe that I can freely speek about delphi here. Even if it is a commercial product.

    I apologize really that I found FMX cool about abstraction side of the system and graphics : This match for me the K.I.S.S. mode, it is working, easy to aprehend. So I speak about : that will never happen again here, I promise.

    FMX have bad design and must be burn by the Inquisition, Okay, I noted.



    I make new design very rarely, and, I confess, despite all my years in coding, I have always diffulty to tag bad or good design in code that I worked on : If the code is efficient in matter of support and modification it will survive. Simple. And I can say to you that quality is not really correlated to its design.

    I understand too that the really main problem for you is the fact it is not game oriented 3d engine and it is close sources, and private held.
    I forget this 2 importants facts, and see only the abstract side : You right, I Apologize.

    --> Certainly, if FMX was open source, you'll find it technically much better ?! LOL (p.s : it's a joke, do not call Torquemada again and ignore this sentence !!)


    No. The main problem for me, and it's really worring me : Why have you need to pass your message in a such condesendant way ?
    Consdescance confirmed after, when, aparently, you are nominating yourself as a keeper of immorality, and keeping "young" people away of bad choice.

    --> You know, when somebody is able to read, he's able to make is own choice without you.

    You are showing the path, and that is your honour, But you didn't build it.


    As you said, we are here because we all love Pascal and game, and that is suffisant : Useless to try to transform it in a holly mission.

    Hope we can exhange later in more positive way.

  3. #13
    I must agree with phibermon about the fact that FMX is not best example of abstracting Graphical API.
    The main reason for this is the fact that in FMX both graphical and logical part are tightly coupled together while most grahpical engines try to keep graphical and logical part uncoupled.
    Keeping logical and graphical parts uncoupled means that logical part won't be slowing down the graphical part or vice versa. Not to mention that it is much easier to implement multithreading support when you have graphical part decoupled from logical part.

    Do you want example to see how logical part can affect graphical part in FMX?
    Simply create a FMX form with let us say 200 panels positioned on it. Compile the project and then go and rapidly move the mouse over the form and you will see significant increase in CPU utilization. On my laptop this is enough to lower FPS below 15 and having 400 panels on the form I can easily lower the FPS to single digits. And don't think that my laptop is weak. It is still powerfull enough to run farCry3 with athleast 30 FPS on medium graphical settings provided that I disable the AntiAliasing and MultiSampling.


    Anywhay when I first tried FireMonkey I was verry exited but got quickly disapointed with its performance.
    And what disapointed me even more is that even with that fraction of FMX code that Embarcadero made avalable (mosty source code for certain components) you can't help yourself much if you decide to go and try creating some custom components.
    So in the end I ended up making my own UI library which is on hold for about a year now. I don't like talking about it to much becouse I feel ashamed that I still haven't gotten it to a usable state even thou I started working on it about two years ago if not even earlier.

  4. #14
    Quote Originally Posted by SilverWarior View Post
    I must agree with phibermon about the fact that FMX is not best example of abstracting Graphical API.
    The main reason for this is the fact that in FMX both graphical and logical part are tightly coupled together while most grahpical engines try to keep graphical and logical part uncoupled.
    Keeping logical and graphical parts uncoupled means that logical part won't be slowing down the graphical part or vice versa. Not to mention that it is much easier to implement multithreading support when you have graphical part decoupled from logical part.

    Do you want example to see how logical part can affect graphical part in FMX?
    Simply create a FMX form with let us say 200 panels positioned on it. Compile the project and then go and rapidly move the mouse over the form and you will see significant increase in CPU utilization. On my laptop this is enough to lower FPS below 15 and having 400 panels on the form I can easily lower the FPS to single digits. And don't think that my laptop is weak. It is still powerfull enough to run farCry3 with athleast 30 FPS on medium graphical settings provided that I disable the AntiAliasing and MultiSampling.


    Anywhay when I first tried FireMonkey I was verry exited but got quickly disapointed with its performance.
    And what disapointed me even more is that even with that fraction of FMX code that Embarcadero made avalable (mosty source code for certain components) you can't help yourself much if you decide to go and try creating some custom components.
    So in the end I ended up making my own UI library which is on hold for about a year now. I don't like talking about it to much becouse I feel ashamed that I still haven't gotten it to a usable state even thou I started working on it about two years ago if not even earlier.


    Hi SilverWarrior,

    Yes, I'm aware of quick performance deprecation you can have with this product : Even in 2D. There are no acceleration structure, so, FMX performance on "stress" is very bad.

    In fact, I spoke about low level part (FMX.Context and FMX.Context.[Platform]) but, even if we consider only this part of the product, certainly many issues could be pointed : More or less, the easyness of technology access seduce me.

    But as I said juste before, and As I recognized, talking about this subject here was a mistake.
    The subject could be closed.


    Scuse me cause I'm not understand : When you speak about your UI library, you build it upon which framework ? OpenGL ?

    Kind regards,

  5. #15
    Quote Originally Posted by Vinzvega View Post
    When you speak about your UI library, you build it upon which framework ? OpenGL ?
    The basc design of my UI library is not to directly interface with graphical API's but instead with already built graphical engines. This is done through special abstract layer which serves as interface between my UI library and the graphical engine being used. This would hopefully alo it to be used with most graphical engines out there wheter they are pascal based or not.
    So in a way it is more like an extension for existing graphical engines. The reason why I chose this approach is that at the time when I was starting to work on it there were several good pascal based graphical engines available like Asphyre Sphinx 3 or ZenGL.

    So basically I'm focusing on high level development. I will leave midle level development (special abstract layer) to the developers or users of specific graphical engines since they have best knowledge of them. It would probably be posible to even develop the middle layer so that it directly interfaces with graphical API's for certain things.

    Anywhay I'm afraid I'm still far from finishing it. It turned out to be much more difficult than I imagined, and my original design has already been replaced a few times

  6. #16
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    I apologize if I caused offence and yes I was not very diplomatic much to my shame. I'm sorry.

    Embarcadero and FMX is very much a hot topic for me - Like many Pascal developers in England I was taught Object Pascal and Delphi at School, College and University - Borland were making a big push to get the language recognized throughout the industry and we were all assured through our national institutions backed by the commercial might of Borland that Object Pascal had a future and it *did*, we all dedicated ourselves and our initial careers to Delphi. And all looked good until Embarcadero took over. Their lack of vision and effort followed by a series of poor quality control decisions that has allowed things like FMX to persist despite *repeated* failures and widespread criticism, things like IOS + Android support delayed for many years and Linux support *totally ignored*? these things basically say to the tens of thousands of people across the world that were counting on Embarcadero : We don't care about your future.

    Delphi was the only thing keeping mine and many other peoples career prospects open. Just a few years ago Delphi jobs were abundant! and they still would be if Delphi had moved with the times.

    Instead of a mighty cross platform system that works on all major platforms with a first rate library to match that of any C++ suite? We get a product stuck on Windows with poor cross platform support that was years and years late (and still woefully incomplete) and FMX : far from being the future of Delphi represents all that is wrong with the decisions made over the past few years. It's slow, badly layed out when compared to the *standard* VCL and enforces a design that makes game development next to impossible on IOS and Android (in pipeline as well GPU resources locked) you know Embarcadero, games? the number one source of revenue on Android and IOS? Thanks for that, really helpful.

    So yeah, not a big fan of FMX on either technical or even general grounds. We should of had enterprise class database development on Linux, seamless RAD across all platforms, Android/IOS support *the moment* those systems came out. We should of had a professional, world class compiler and tool-chain. Instead we get animated buttons on IOS. Great. So for me the push for FMX is why Delphi is *no longer* the worlds greatest database client development tool and why mine and many thousands of people's careers have been ruined.

    I wouldn't mind having support for other platforms years too late, I wouldn't even mind the total lack of Linux support (you know Embarcadero? the world standard in database servers? Delphi was the world standard for database client development? are you literally not seeing this?) But for FMX to be so *badly* designed as to be unsuitable for exploiting the main revenue streams on the platforms it was designed for? it's nothing short of insulting given the dedication that I and many people have shown in the past.

    I hope FMX turns into some amazing fully capable system and we see support for spinning, hardware accelerated buttons on all major platforms and I wish all of its users happiness and joy.

    But I won't be recommending FMX for games development and indeed I wouldn't recommend any other proprietary tech that ships with Delphi. It's too much of a gamble on a company that doesn't care about your future. Use open-source / standard libraries and API's even with Delphi - that way your hard work and effort will survive any poor commercial decisions.

    I do want to see a brighter future for the language and for those looking to develop games in Pascal I do want to be able to recommend and advise what I objectively see as the best options.

    I apologize again for my tone, it is unjustified unless you actually have an affiliation with Embarcadero - I just don't want anybody else's careers ruined on the promises of a company that can't deliver and the thought of an Embarcadero employee pushing FMX as suitable for games development in light of this made me angry. In such a context it is nothing short of greedy lying at the cost of people's future. Given that I can't see how anybody but an Embarcadero employee would recommend FMX? I assumed you were.

    I'm sorry. I will now go and write a tetris clone with FMX as way of penance
    Last edited by phibermon; 02-02-2015 at 06:39 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  7. #17
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by SilverWarior View Post
    So in the end I ended up making my own UI library which is on hold for about a year now. I don't like talking about it to much becouse I feel ashamed that I still haven't gotten it to a usable state even thou I started working on it about two years ago if not even earlier.
    looking forward to seeing it! I wish you'd release it I've not released mine specifically so I don't step on your toes
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  8. #18
    Quote Originally Posted by phibermon View Post
    looking forward to seeing it! I wish you'd release it I've not released mine specifically so I don't step on your toes
    Wait what? Did I read this right? Are you realy waiting with the release of yours as to give me a batter chance of sucsess?

  9. #19
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by SilverWarior View Post
    Wait what? Did I read this right? Are you realy waiting with the release of yours as to give me a batter chance of sucsess?
    More because you showed such passion for creating a multi-purpous UI and had so many ideas that I didn't want to detract from your work. There's no decent existing UI like you've got planned available yet and if I were to release mine you might lose some potential users simply because they'd integrated mine before you'd had chance to finish even though yours may very well be better for them.

    My passion is for my game engine I'll hopefully get some appreciation for my engine one day and I can live with downplaying my UI work so that you may get the maximum respect for something you're passionate about too
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  10. #20
    Wow! I don't know with what did I earned such respect from you but I'm honored you think that way about me. I just hope I won't disapoint you in the end.

    Anywhay you don't need to wait for me with publishing of you UI library. The main reason is that I have no idea when it will be finished. It may take a while especially if development will be as slow as it was in the last year.
    Anywhay if I achieve desired quality of it I don't think it would matter much wheter it is published first or not. Besides I may even get some good idea from looking at yours.

    But the main two reasons why you shouldn't wait for me is:
    1. Now that I know you are waiting for me it makes me feel presured which I don't like. Why? When I'm presured I tend to rush things. And when I rush things I tend to make many silly mistakes becouse of which the development takes even longer than it would othervise. This is one of the reasons why I didn't decided to join you in development of your UI library when you invited me to.
    2. Based on feedback from many indy game developers that I'm in contact with (mostly giving suggestion on improving their games) I can tell you that most of them are quite frustrated by the fact that even good game engines usually come without decent UI library. Most of them only support verry basic UI library which usually isn't good enough for making decent good loking game UI. So many of them actually had to ither exted those basic UI libraries that come with the game engines they use or make their own. And this is another reason why I'm trying to develop my UI library in such way that it could be used with as many graphical engines as posible.
    You say that your pasion is your game engine. Well including your UI library in your game engine would inprove its value greatly and therefore also its sucsess.

    So don't wait for me and take care about your sucsess first. Especially since in the end I'm thinking about opening the source for my UI. But I won't do this now becouse I'm afraid that doing so I might be caried away from my initial idea too much.
    And for those wondering yes I do intent to shift the focus of my UI library to fully support PGDCE first. But I first need to do another partial rewrite to support another feature that wasn't planned in the beggining but I have seen it requested by some pepole on the internet and my overal design alows pretty easy implementation of it.But I do need to implement it first before I write a design document of what exact capability is needed from the grapgical or game engine so that my UI library can be used with it.

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL