Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: Abstracting Graphical APIs

  1. #21
    Hi Phibermon,

    Thank you for your gentle response. I understand much better your reaction now.

    Sorry on my side to not understand that more quickly.

    I understand now too at what level you suffer about all the 5 last years of delphi actuality. I lived that with more distance, because not directly stuck with this market : I confess that when EMB bought the FMX technology from a component supplier and out DXE2 with IOS support throught FPC I honestly believe that was a proof of opening, and was very excited about. I was wrong. Sincerly, I'm just a little more optimist (naive ?) than you

    You now, I grow up too with turbo pascal and Delhi1/2/3 and it was a fabulous period : I was angry when people compare it to VisualBasic, in this time already, Delphi began to be not well understood : Native compiler, advanced VCL : tremendous.

    Today, Delphi change (not the VCL, despite the fact it is alway supported, good point !) RTL change, low level change and this new GUI library. Then, come the first problem with compiler deprecation and FMX "yoyo" quality, and persistant bugs. I excused all of that for 2 reasons : FMX was young technology and EMB was (is) alone in the market to get a chance to put Pascal again in front scene. All the other compiler, despite their top technical quality, is far behind. It is sad, but it is.

    So, I shared near of all your technical analyze of EMB act about delphi : It is unfortunally true. But when you enumerate all the problem in one time, it is so hard to hear :/
    In fact, the fact that EMB target only money (It is a Fund, behind EMB, and this is terrible for a firm, nothing count unless money behind the corporate action holder decision) is a kind of justification of the sad way taken by delphi today.

    But I want to be more optimist : Perhaps, from those bad seeds, could grow again a beautifull and strong tree ? I hope. And for me, community is very important for that, but I see here and elsewhere (torry, Delphi.de) that community is less and less present. That is entirely the consequence of EMB act. You right again.
    The worst, is that after all this heavy delphi break, EMB try with a new brand (appmethod) to get new people : I think this a loss of energy : Hope it will have good consequence on Delphi EcoSystem, but I doubt.

    Hope, as you do, all will be better later. After the war, there are rebirth. Normally..

    If, as a redemption, you make a Tetris in FMX, I'll install FPC (command line) and start make OpenGL stuffs with it right this afternoon !
    (Ok, it is not really a punishment, but what to do else ?)

    By !

  2. #22
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Oh don't feel pressured or anything, I've got so much work to do on the engine and now with PCDCE as well that I doubt I'll be releasing anything for at least a year And in terms of respect? You care about the community as much as anybody could, you do your best to help people, you're polite, courteous and objective when it comes to ideas. If PGD had a dozen of you it'd be one of the best programming forums let alone the best Pascal forum. You have my fullest respect

    Yes I intend to release the UI with the engine, it's as capable as any tool-kit GTK etc and has full window management like any OS/Window manager. While the Game engine is openGL only the framework it sits in has a built in 2D engine that has abstracted renderers for Win32/Graphics32, OpenGL, Quartz and a VESA optimized renderer (I was hoping to get it running on CoffeeOS but it'll be a while before that's possible). JUI (the UI) relies on a few parts of the framework and is concidered an add-on like the game engine is. The framework on its own is basically a pascal equivalent to SDL. The UI can render in single-buffered region invalidating mode, direct render, double-buffered with renderbuffers per window (or control), double-buffered direct and a hybrid double-buffered invalidated mode that's optimized for real-time rendering with a number of windows. It times how long it takes to render any region, window control etc and selects the quickest render-path from various buffer/direct schemes for subsequent renders.

    The UI also has an 'App' class container to allow it to operate on an OS like level. You can use taskbars/lists for running apps, you can define app dependencies and triggers (for example in my engine tool (JinkEd) if you delete, for example, a camera entity with a camera view app open, the view app will be destroyed as the camera entity is destroyed) the apps can be entirely scripted, directly coded and run in separate threads (and render in separate threads with certain paradigms although on fast GL hardware this render-path is rarely chosen by the manager and is more an optimization for software rendering). It's possible to run any window or indeed any control in it's own thread. Not that you would, but you can. Because scripts are isolated and can run any block in a separate thread it's possible for just a button to crash and the rest of your app to carry on working. (This is also the case with hard-coded elements although writing in this multi-threaded crash aware way is not for the faint hearted)

    As well as all the usual menus, drop downs, listviews, treeviews, buttons, radio-groups, sliders, labels, edit boxes etc I've also written some specialized widgets for use in my engine and music studio such as a fairly advanced time-line control for piano rolls (also used for editing the timing/lifespan of mutators in my particle systems) and more uncommon add-ons like widgets for docking and stacking apps into toolbars. It's all unicode and it supports drag and drop internally (trees to lists etc etc) as well as file path drops from windows/linux and osx.

    It has anchors for all elements, splitter controls etc. So any layout/resizing scheme you've ever seen in an app can be achieved. Naturally all item and header classes will scale according to the font used, border properties etc You can use different fonts, colours and themes/skins for every single control or window.

    It supports custom rendering of any element so you can have skinned interfaces, it includes both square and rounded geometric base classes you can customize and yes it can do all of the silly firemonkey like animation stuff, it can spin and scale any window/button smoothly. Transparency fully supported, 3D rotations, explosions blah blah blah. I really didn't want to add such superfluous things but it's there should anybody really want to use it.

    It's primarily designed for OpenGL. It has a pure vertex rendering mode and a customizable shader that allows you to render a very complex UI with thousands of controls without using any GPU memory beyond the loaded shader (you can easily plug it into one of your existing shaders if you have something suitable to save that last little bit of memory) or if memory isn't at a premium you can allow it to create buffers in graphics memory for increased rendering performance. You get to balance performance against memory use as much as you like. I did write a full VBO mode with a past UI that drew everything (including text) but I found that even on really old hardware with thousands of buttons, there was only a marginal performance gain over just using a VBO packed with a few primitives that you reuse to draw everything. Optimized rendering is therefore handled with the buffering/region invalidating raster methods.

    The region invalidation works with a special type of widget I have called a Viewport which is used to render 2D/3D custom stuff (so a game for instance). If you decide to handle the callbacks you can have a realtime 3D window that will only re-draw visible portions by way of sending the viewport/camera projection data to the render-pass for the given visible regions

    Because it's primarily designed for real-time rendering it also has frame-limiters etc you can use for viewports and you can have Pseudo double-buffering in a single-buffer context so if the user decides to make use of it, one window can be maxed out at 5fps (or locked while a complex scene is rendered) while another window can be churning along at 60fps.

    It has primarily been coded on demand while creating a real-time 3D game engine tool that is similar to Blender/Lightwave in capabilities so if you're looking to create a front end to a ray-tracer or want to make the next blender, it's very well suited to the task.

    Oh and it can render on a 3D surface inside the game engine itself, either directly with vertex/texture data or purely buffered on a texture. So you can use it to create computer interfaces on doors AKA Doom/Alien Isolation (I suppose the animation effects would be more suitable in such a context) You can also create a GL context and have it aligned with a software rendered window allowing you to encapsulate any GL engine which wasn't designed for or overrides scissors/viewports.

    The one thing it doesn't do which I wanted is a client mode where each JUI window is created as a window in the OS, hiding the window frame and using the JUI controls instead. It's possible but I've not written it (yet) you can however hide your window frame and link resizing etc with callbacks to a single JUI window. Dialogs would be better as seperate windows (to be more 'compatible' with Oses like windows) so I may add it eventually.

    All in all, I wish I'd never started on the UI. I'd of finished the game engine by now
    Last edited by phibermon; 03-02-2015 at 03:23 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  3. #23
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by Vinzvega View Post
    Hi Phibermon, Thank you for your gentle response. I understand much better your reaction now.!
    Thank you for being gracious and accepting my apology

    I would dearly love to see Delphi at the top of the tree again. A product that I can say to anybody "You want to make games? 3D applications? you want to get to market faster with a more stable code-base than your competitors? use Delphi". I do understand why EMB have made the push with FMX, I totally get it - I really do. I just think they're totally wrong in doing so. I'm sure that mobile platforms were at the top of the wish list for users - I'm also sure that what they wished for was comparable support to C++, access to the standard API's. EMB ticked the right box, they used the wrong pen.

    Delphi is great, it should be right up there on the front page of Slashdot, not laughed about in some random comments at the bottom of a post about alternative languages. At the very minimum, the commercial, expensive Delphi should be far better and more capable than a free alternative. They're getting paid to make it, it should be the best.

    Sadly that's not true, Freepascal (and in many IDE respects, Lazarus) supports far more platforms, has a more complete (and standard) API for all of the mobile platforms - it's just a better compiler.

    I'm happy that I've got a good cross platform Object Pascal compiler. I can do *everything* (sans target some specific propitiatory platforms like the Xbox) in Object Pascal that I can do with C++. There's nothing but my skill and time stopping me. But that's thanks to Freepascal. It *should* be thanks to Delphi.

    Delphi (XE7) at absolute minimum price of 1526 to target all supported platforms, I can only hope to match my C++ rivals on Windows. That's it. I sure as hell can't compete on IOS and Android without access to the standard API and FMX taking up resources I need and enforcing a design I can't work with.

    I think that's rather sad :\ I would love to see Delphi at the top of the tree, I've loved it, I've been dedicated to it. I was *proud* to be a Delphi developer.

    Delphi is arguably a better IDE than Lazarus and does have some fantastic RAD database components - but at the price of a small car to get the functionality everybody else gets as standard, it's not enough. Especially without Linux support (And I'll be kind and forget the rest)

    They should cater for us too, the lone games developers, the small teams. Games are the biggest source of revenue on mobile platforms, it's a fact. And I and everybody else here says Object Pascal is a fully capable language for game development, we know it is, we're doing it right now. In Freepascal - again, it should be Delphi. Would it really kill them to give us a cross platform Delphi at a decent price? dump all of the components! give us a cross platform compiler and the Delphi IDE, surely EMB can do that at a price we can afford? Their price list is proof that it's the components that make up a vast amount of the cost. Starter + Mobile pack would be 713! I'd *almost* stretch to that (with Linux support) just to be able to use the Delphi IDE. But I've got to pay 800 more for a bunch of components I don't want just to be able to target Android and IOS?

    --

    Off topic.

    I think we should all agree not to discuss religion, politics or EMB pricing
    Last edited by phibermon; 03-02-2015 at 03:35 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  4. #24
    Quote Originally Posted by phibermon View Post
    And in terms of respect? You care about the community as much as anybody could, you do your best to help people, you're polite, courteous and objective when it comes to ideas. If PGD had a dozen of you it'd be one of the best programming forums let alone the best Pascal forum. You have my fullest respect
    Yes I do care about comunity greatly. Why? As a self taught Delphi programmer I know how hard it can be when you don't know where to turn to get help. When I started learning to program in Delphi its popularity was already in slow decline (that was short before Borland gave up on Delphi). And the only comunity that I was present at the time was Delphi-si comunity which was mostly populated by expirienced busniess programmer who had verry litle intention to try and understand what wild ideas I was trying to do and then help me out.
    And boy did I had some wild ideas then (making shell replacment for windows, creating my own drivers for a custom controller - steering wheel that I made, DJ mixing software, etc). When I think about theese ideas now they don't seem so crazy becouse my programming knowledge is probably good enoigh to finish athleast some of them but then my programming knowledge was still far to weak to do anything like that.
    So yes becouse I know how hard it can be at start I try to help whenever I can even to total newbies.

    Quote Originally Posted by phibermon View Post
    Oh and it can render on a 3D surface inside the game engine itself, either directly with vertex/texture data or purely buffered on a texture. So you can use it to create computer interfaces on doors AKA Doom/Alien Isolation (I suppose the animation effects would be more suitable in such a context)
    This is also one of the planned feature of my UI.

    Quote Originally Posted by phibermon View Post
    All in all, I wish I'd never started on the UI. I'd of finished the game engine by now
    Don't say that! While you are probably not aware of it I'm willing to bet that doing both at the same time actually lead your into making both UI and game engine better as you would do it othervise. Why? Becouse by doing it so you ran to various quirks and difficulties that are specific either for UI or for graphical engine and adjust the designs of both JUI and your game engine to either avoid them or solve them.
    Why I think like this? When I started working on my UI library I thought that all I will have to do is write a few methods which will fire several combinations od draw procedures and that is it. But soon I realized that for making of a UI library much more is required like:
    1. Input handling: Without ability to handle user input your UI is not Ui but jst a graphical interface
    2. Rendering loops: In order fto render you UI in proper way you need to learn about rendering loops
    3. Sceene managment: While this might seem unimportant at first look it is quite important especially if you don't want to draw your whole UI right from scratch every rendering cycle. Reusing of already rendered or should I say composed scenes that hasn't changed from previous rendering cycle is the main way of optimizing your rendering cycles.
    4. Resource managment: Again at first this might even seem as not neede at all but you quickly realize that it isn't so. When I'm saying resource here I don't only have graphical resources in mind (texutres) but also any other data that you require for your UI like controll positions, controll states, etc.

    Anywhay we are getting a bit off topic here. I just hope that we haven't scared Anton with to much information here

    @Anton
    How ever you decide I'm sure you can count on the help from more knowlegable pepole here on PGD when you will need it.
    Unfortuantely I can't count myself into that group but if you will need any help in working with classes I belive I could be usefull as I belive I have pretty god knowlege about them. Not so much about interfaces but that is mostly becouse I myself don't see the need to use them. So far I have always managed to solve everything with classes alone.

  5. #25
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by SilverWarior View Post
    Yes I do care about comunity greatly. Why? As a self taught Delphi programmer I know how hard it can be when you don't know where to turn to get help. [...] So yes because I know how hard it can be at start I try to help whenever I can even to total newbies.
    I try to as well, it's good to have others working towards the same goals



    Quote Originally Posted by SilverWarior View Post
    This is also one of the planned feature of my UI.
    it's cool isn't it? I have a tech demo for my engine where there's a computer on a desk and the computer is 'running' a cut down version of the music sequencer I'm writing for the engine. I wrote a 3D front end for mame many years ago that was a room filled with arcade cabinets and each arcade machine would be running a seperate MAME emulated arcade game. At the time I lacked the 3D modeling experience and ability to work with C++ code to make it anything other than a proof of concept. But the whole idea of a system within a system in that way is very cool


    Quote Originally Posted by SilverWarior View Post
    Don't say that! While you are probably not aware of it I'm willing to bet that doing both at the same time actually lead your into making both UI and game engine better as you would do it othervise. Why? Becouse by doing it so you ran to various quirks and difficulties that are specific either for UI or for graphical engine and adjust the designs of both JUI and your game engine to either avoid them or solve them.
    This is true, I can't say I've created the best UI but I can definitely say that my UI is suitable for use with a game engine!

    Quote Originally Posted by SilverWarior View Post
    1. Input handling [...] 2. Rendering loops [...] 3. Sceene managment [...] 4. Resource managment
    Yes All have been key considerations and the design of the both the UI and game engine would be different if it wasn't for the existence of the other. The game engine developed in tandem with the UI and scene editing tool has resulted in a design that can be what you need it to be with the bare minimum of effort on part of the user. There's nothing in the engine that can't be controlled with UI elements, it's forced me to implement a consistent and simple interface.

    Same with the UI, the way input is handled between the two, the way it renders, specifics that don't come into play with standard UI development (managing the depth buffer, minimizing texture memory use, self optimizing render paths etc) - Many things are the way they are because it's best for using the 3D hardware along with a 3D engine.

    Yep and off topic, my apologies, I do tend to ramble
    Last edited by phibermon; 03-02-2015 at 03:55 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  6. #26
    Quote Originally Posted by SilverWarrior
    Anywhay we are getting a bit off topic here. I just hope that we haven't scared Anton with to much information here

    @Anton
    How ever you decide I'm sure you can count on the help from more knowlegable pepole here on PGD when you will need it.
    Unfortuantely I can't count myself into that group but if you will need any help in working with classes I belive I could be usefull as I belive I have pretty god knowlege about them. Not so much about interfaces but that is mostly becouse I myself don't see the need to use them. So far I have always managed to solve everything with classes alone.
    Oh, on the contrary, I find everything very interesting. I didn't post anything since I solved my problem by not making such a layer. Thanks for your help. I'm now writing a small library for rendering in D3D11. About interfaces, for the last year or two I began to love working with interfaces.

    As for FMX I can't really comment, since I have no experience with it. The only thing I know is from other people that it is heavy in terms of performance.

    Quote Originally Posted by phibermonn
    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
    This is very interesting. Can you tell more? What features do you plan/support in your engine /do you have a demo video?

    You now, I grow up too with turbo pascal and Delhi1/2/3 and it was a fabulous period : I was angry when people compare it to VisualBasic
    it should be right up there on the front page of Slashdot, not laughed about in some random comments at the bottom of a post about alternative languages.
    Yeah, this is sad. Very often I meet people with novice skills on programming (in lets say C/C++) to tell me that it Delphi/Pascal is not a serious language (more like something which someone invented because he had much free time) but maybe this is more a mainstream unconscious view, rather than objective. Most of the times when I mention "Delphi" often people ask me "Does anyone use this anymore?" BTW, I have seen forums with people fighting C against C++, so what's left for C++ against Delphi.

  7. #27
    Quote Originally Posted by phibermon View Post
    it's cool isn't it? I have a tech demo for my engine where there's a computer on a desk and the computer is 'running' a cut down version of the music sequencer I'm writing for the engine.
    I don't have anything as fancy as you. Not yet anywhay. But when I manage to finish my UI ... Let just say that I already have a few dozens ideas about how I could use this

    Quote Originally Posted by phibermon View Post
    Yep and off topic, my apologies, I do tend to ramble
    I sometimes also have huge urge to share my thoughts so I'm guilty aswell

  8. #28
    Quote Originally Posted by Anton View Post
    Yeah, this is sad. Very often I meet people with novice skills on programming (in lets say C/C++) to tell me that it Delphi/Pascal is not a serious language (more like something which someone invented because he had much free time) but maybe this is more a mainstream unconscious view, rather than objective. Most of the times when I mention "Delphi" often people ask me "Does anyone use this anymore?" BTW, I have seen forums with people fighting C against C++, so what's left for C++ against Delphi.
    When I talk with other programmers about Delphi/Objet Pascal their response is usually something like this:
    1. Programmer that have never done any programming in Delphi/Object Pascal: "What Delphi? You can't do any serious application with it. You need much more than simply placing some components on the form."
    And the main reason for their response to be like this is that Emb arcadero always advertise how Delphi comes with bunch of usefull components, Live Bindings, etc but rarely advertize any language properies. Only recently you could see a few of new language features being advertized like Generics, Advanced Referencing, etc.
    2. Programmer that has athleast tried doing some programming in Delphi/Object Pascal: "That isn't a bad language but I don't think it is capable enough for some serious applications. There arent many usefull examples or libraries for it available."
    3. Programmers that have done quite some prgramming in Delphi/Object Pascal but have switched to other programming languages: "Pretty good language, lacking some of the newest features. Has rather poor and dwindling comunity and its development IDE is verry expensive. So it is better that you switch to some mainstream language soon if you want to be able to get any programing job in the future".
    What these guys fail to realize that they are the main reason why the comunity keeps getting smaller and smaller. But stayung wold mean that they wouldn't have acces to the newest windows features like those that come out in .NET programming language.

    So one day I have asked one of them who migrated from Delphi/Object Pascal to Visual Studio/.NET: "Why have you decided to migrate to .NET?"
    And his answer was: For the software I'm developing I requires access to NFC hardware."
    So my next question was: "Isn't there a library for Delphi available that would support this."
    He says: "No ther isnt."
    So I ask him: "Have you considered making such library yourself?"
    He looks at me and goes: "Are you crazy? Why should I spent several weaks or perhaps even a month designing and implementing such library if one already exists for .NET?"
    So my next question was: "Could you share how much time have you spent porting your application from Delphi to .NET?"
    His asnwer that he harldy said it was: "I have spent four months proting the code to .NET"
    And my response was: "So you spent four months porting your whole application to .NET instead of spending one month implementing the missing library. It haredly seems woth it"
    And then my final question was: "How many new bugs have crawled in during the porting of your program?"
    I have never got the answer to the last question. I hues that is becuse I hit the nerve of that programmer with it. He definitly knew that the choice of porting the whole application to .NET just becouse of one library was a poor one but he wasn't prepared to admit it.

    Anywhay when someone asks me as to which programming language they should use I usually say something like this:
    "Chose the one whose sintax structure suits you more. It is definitly better to program in programming language that feels natural to you and lack some features becouse in the end you can probably implement them yourself rather than programming in a programming language that offers you all of the features but you are having problems with its sytax structure becouse it doesen't seems logical to you.
    It is like talking in foregin language. You can easily learn meaing of certain words but if the languages syntax isn't logical to you you will have realy hard time creating a meaningfull sentace out of those words."

  9. #29
    We are getting far away from the topic by the way

    Yeah, I agree that everyone should use that language/tools which fits them better and makes them comfortable.
    I see a tendency, anyway, that people would reject to learning something which looks simple, but prefer complex-looking thing (with more symbols, slashes, all kinds of braces, etcetra) for the aim that they look smarter in world's eyes (which I doubt is a smart choice by itself).

Page 3 of 3 FirstFirst 123

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