Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: What Perl CAN'T do?

by strat (Canon)
on Dec 14, 2005 at 09:13 UTC ( #516562=note: print w/ replies, xml ) Need Help??


in reply to What Perl CAN'T do?

I think perl (especially in combination with XS) can do nearly everything. But some things don't make sense because there exist faster solutions, e.g. 3D programming (Corion showed me at the last frankfurt-pm-meeting that it can be done, but it isn't very fast; a 3D shooter like quake wouldn't give enough frames per second to be comfortable enough on a common PC) or system drivers.

Btw: Perl/CGI usually seems to be a little bit slower than ASP, but you can probably use mod_perl. And comparing Perl/Tk to VB is a bit like comparing oranges and plumns, since AFAIK in VB you can only use objects, whereas in Perl you can create your own ones (may have changed with .NET, I don't know). And often, the VB-GUI looks more like a windows application than Tk where some widgets look ugly, e.g. Tk::Notebook or Tk::Combobox. But if that is essential, you can as well use wxPerl instead of Perl/Tk)

Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"


Comment on Re: What Perl CAN'T do?
Re^2: What Perl CAN'T do?
by Courage (Parson) on Dec 14, 2005 at 17:09 UTC
Re^2: What Perl CAN'T do?
by hardburn (Abbot) on Dec 14, 2005 at 20:13 UTC

    a 3D shooter like quake wouldn't give enough frames per second to be comfortable enough on a common PC

    If it was limited to using the CPU only, the recent Quake games couldn't work in C/ASM, either. You have to offload operations to dedicated 3D hardware to get Quake-level graphics. You need underlieing library support to take advantage of GPUs, which Perl has.

    In the game I've been writing in Perl (2d sprites, not 3d), the biggest CPU-hog is collision detection. I'm using a rather naive algorithim (every object tested against every other object), so it does a lot more work than it needs to. With offloading some of the calculations into C code, the game is playable on my 2.2 GHz Celeron laptop (but only just so in some spots). In pure Perl, it's easily playable on my Athlon64 3200+ (2.0 GHz) desktop.

    Fortunately, collision detection shouldn't be difficult to paralleize (at least from what I've seen so far), so this is an area that can take advantage of multicore processors. Also, there has been some research on using GPUs for collisions.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      One very simple way to optimize collision detection is to sort the objects by pos.x (or y) first. Now you know a lot more about which objects are in proximity.

      I'm sure there are really clever rocket science grade algorithms for this too :)

      /J

Re^2: What Perl CAN'T do?
by Qiang (Friar) on Dec 15, 2005 at 17:17 UTC

      Well, then it should run as good as under perl, shouldn't it?

      Best regards,
      perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://516562]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (10)
As of 2014-07-25 11:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (170 votes), past polls