Slashdot Mirror


OpenGL in PHP

Neophytus writes "Submitted as an entry into the .geek PHP5 tournament a proof of concept openGL implementation in PHP has been released by Peter 'iridium' Waller. The demonstration (download) shows four items being rendered in realtime by PHP at a not unreasonable 59FPS. The author welcomes feedback with practical uses for this technology." Update: 06/09 01:10 GMT by T : iridiumz0r, author of this entry, adds a link to this informative page responding to a number of comments in the discussion below.

16 of 286 comments (clear)

  1. Using the right tool for the job by Cardinal · · Score: 5, Insightful

    ...Is truly a lost art.

    Of course, we already knew this.

    1. Re:Using the right tool for the job by Saeed+al-Sahaf · · Score: 4, Insightful
      So why not php?

      Because you don't have to be a "guru" a la Perl to right functional programs with it. Same reason people here hate VB.

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    2. Re:Using the right tool for the job by pizza_milkshake · · Score: 4, Insightful
      It's a turing complete language

      so is Brainfuck, but i wouldn't consider it the right tool at any time.

    3. Re:Using the right tool for the job by FuzzyBad-Mofo · · Score: 2, Insightful

      I don't hate VB because non-coders can use it, I hate VB because it forces me to think like a non-coder in order to use it.

    4. Re:Using the right tool for the job by loginx · · Score: 3, Insightful

      And perl was designed for text processing.

      Languages evolve as more great developers join the core development teams and change the behavior and functionality of the language.

      A good language is a language that can evolve beyond what it was designed to do and scale well.

      PHP and Python are such languages.

    5. Re:Using the right tool for the job by GnuVince · · Score: 2, Insightful
      Python is fast has a superb set of built in functionality and very flexible, and has great OO support.
      Ruby is fast has a superb set of built in functionality and very flexible, and great OO support.
      Smalltalk is fast has a superb set of built in functionality and very flexible, and great OO support.
      Common Lisp is fast has a superb set of built in functionality and very flexible, and great OO support.

      Nothing about PHP makes it more suited for this job. Also, PHP is a language that was made specifically for web pages and turned into a general purpose language because of some mad scientists. On the other hand, Python, Ruby, Common Lisp and Smalltalk are all general purpose languages, and were made that way from scratch.

    6. Re:Using the right tool for the job by runderwo · · Score: 4, Insightful
      Nice troll. The problem is more like that with PHP you can "right" programs that work with a minimum of effort. That sounds great, but the issue shows up when that code is handed to someone else. Debugging someone else's code in a language that enforces structured programming pragmas as little as possible is a nightmare. I know this because I do it on a regular basis.

      PHP is like MySQL, and it appeals to the same group of people. It works, most of the time. When it's not sure what to do, it does _something_ rather than annoy the programmer, which might even be the wrong thing. When it does something that might be the wrong thing, it does it silently whenever possible so there is no "squeaking" on the outside. The result is that PHP programs work most of the time, like MySQL. That sounds great, but they also have a tendency to fail in unexpected murky ways.

      BTW, there is no need to be a "guru" to write Perl programs. An understanding of the syntax, as well as basic structured programming/OO principles is all that is necessary to create fast, reusable, and reliable Perl code. The problem is that frequently people lack the latter, so they jump on a language like PHP which lets them get away with not having to know such things. Such people view PHP as superior and Perl programmers as pretentious language snobs because they can do in 5 minutes in PHP what would have taken them an hour to learn how to do in Perl. That in no way invalidates the viewpoint of the Perl snob. PHP is a half-ass hack of a language that happens to be preferred by the majority of half-ass hacks of programmers out there.

      Note, this is not a flame at PHP developers. I know some really good ones. I'm flaming people who suggest that PHP is a better language because it doesn't make you learn anything about software design principles. That's precisely the reason I avoid other people's PHP code whenever possible and don't recommend its use in a business environment where software infrastructure quality counts towards the bottom line.

    7. Re:Using the right tool for the job by Canberra+Bob · · Score: 3, Insightful

      "Debugging someone else's code in a language that enforces structured programming pragmas as little as possible is a nightmare. I know this because I do it on a regular basis."

      Same here, and I totally agree with you. If something goes wrong, I want to know about it, not have the program / database decide for me what it should do with it. I think your problem was you mentioned something bad about MySQL in a PHP story. The LAMP zealots are amongst the worst. MySQL will accept date types like 2004-15-60! Having to support quite a number of apps, I want to know the moment something funny happens, not find out a month later when the end user is pulling a report.

      For simple web apps (eg shopping cart) I advise people to use LAMP due to its simplicity. Anything larger and I advise people to stay well clear and go with something like Java (or Perl) and Postgres. This forces the designer / developer to think in large terms to begin with. May seem like a waste of time early on (and it is if you know for certain your app will not grow) but when you start scaling up, it will save a total rewrite.

  2. Just a wrapper by Theatetus · · Score: 3, Insightful

    Well, it's not a port or an implementation; it's a wrapper to a DLL. That's the fun of dynamically loaded libraries: you can call opengl, gtk, qt, COM, CORBA, $WHATEVER_YOU_WANT from $WHATEVER_LANGUAGE_YOU_WANT as long as you take the time and effort to write a wrapper label, which this guy did, and he wasn't the first.

    --
    All's true that is mistrusted
  3. The spirograph is definitely the coolest by caryw · · Score: 2, Insightful

    So why not have 5 of them?

    Here's the slightly altered code. (right click, save)

    - Cary

  4. Re:Running This by rffmna · · Score: 2, Insightful
    Thanks for instruction.

    I get ~113 frames per second...double the "official" number.

    I also wonder what the FPS depends more on..CPU, to interpret the PHP, or graphic card, to render textures...hum..

    --
    -------
    FM Clan
  5. Re:Correct me if I'm wrong, but... by DeltaSigma · · Score: 2, Insightful

    At least it let me know about the useful ffi extension. If it wasn't for this cute demo, I'd have never come across this.

  6. Performance is irrelavant here. by HFXPro · · Score: 2, Insightful

    First I would like to point out that it is still making calls to OpenGL functions which were written in C (and asm most likely). Since PHP is a scripting language and in this case it is calling the OpenGL functions most of the work is being done in the OpenGL calls. Therefore it should run pretty well because most of the delay will be resulting from the C function calls. Scripting languages and all interpreter languages should do well even for simple scenes. They do slow down when you have a lot of logic going on however, such as updating a world model graph.

    --
    Reserved Word.
  7. Re:PHP OpenGL on SourceForge by pcmanjon · · Score: 2, Insightful

    I don't know what submitter of story's problem is with his computer only getting "59FPS." but I seem to get 120. Weird.

  8. Re:Practical uses for this technology by Fryboy · · Score: 2, Insightful

    When's your next Slashdot Meetup??

  9. Re:Ha!!! by groomed · · Score: 2, Insightful

    This process is still young, but the eventual direction this will take is 3d apps over PHP and the web.

    No, for the simple fact that this project is not headed in that direction. It does not provide for 3D apps over the web.

    It's bound to go that way.

    No, because in order for it to go that way, a terrible amount of work would need to be done, and the end result wouldn't provide anything that doesn't already exist.

    I think it's extremely viable for a plugin to be designed that will use this, and many will adopt it for websites as a result. Why the hell wouldn't they?

    Because PHP is not very well suited to the task, and better solutions exist. This hack is on the order of building a toilet out of LEGO's. Possible, but neither viable nor a harbringer of things to come.

    It's not a totally bad idea, just one that scares me somewhat, if it's used maliciously.

    I don't know that you know what the idea is here.

    There are systemic misuses and outright exploits. I am sure that any new system has both.

    There is nothing new about this "system". It's just another computer program.