Pyrel dev log, part 2

[ekolis]

Hmm, I got wx 1.0.0 by running "pip install wx"... guess pip is out of date?

[ekolis]

Nope, I still get the same error with the latest stable release of wxPython (2.8 something). I even deleted the 1.0.0 folder from c:\python27\lib\site-packages...

[LostTemplar]

I'd switch to OpenGL-based rendering.

How it come to this, so OpenGL is faster then just character display. It is definitely something TERRIBLY wrong with modern systems.

[ekolis]

Or terribly right... OpenGL can run on a GPU, which is much faster than a CPU, but limited in what kinds of things it can do. Now, if someone could come up with a way to run character-based terminals on a GPU... hey, didn't nethack.org have a joke about that once?

[ekolis]

OK, what the HELL? Noticed that wx.py is only 238 bytes, so, I opened it up... here's what it contains:

# -*- coding:utf-8 -*-

"""
µ¿íµïƒ PHP σç╜µò€ file_get_content
µêæτÜäPythonµ╡ïΦ»& #242;µ¿íσŽù
"""
def file_get_contents(file):
file = open(file)
data = ''
for line in file:
data = data + line

file.close()
return data

This can't be right... did the installer just save the DOWNLOAD SCRIPT onto my Python installation or something?

[LostTemplar]

GPU, which is much faster than a CPU

2d graphics should run on GPU too, if it does not then....

Anyway form the point of view of an application character display should be just transfer of few bytes to some buffer, actual display code does not matter, it may be even sent over SSH to other host to display.

[ekolis]

You can run 2D graphics on a GPU, if I'm not mistaken...

[Therem Harth]

You can, but most toolkits don't. If you want to know why, try running KDE 4 on a netbook.

[Derakon]

The display code in Pyrel is graphically blitting images of characters onto a canvas; it's not actually a text display. If you do that, in software, 1920 times per update (1920 = 80 * 24), then you're liable to notice a certain amount of slowdown. I once wrote a game using the SDL 2D game library and it couldn't maintain a smooth framerate if there was more than ~500 objects onscreen at a time, so that's not really unexpected.

A text-based approach would be significantly faster, but then you'd have to completely rewrite the display layer if you wanted to handle tiles, or layering, or variable font sizes, or any number of other special things (partially-transparent spell effects?). Pyrel's implementation is all about saving developer time; computer time is much less valuable. Later on if someone wants to write a pure-text display (e.g. so they can run Pyrel in a console window, or over SSH) then they're welcome to do so, and it should work just fine.

[ekolis]

Any idea what's happening with that error, Derakon? I even tried copying the wx-2.8-msw-unicode folder from C:\Python27\Lib\site-packages to C:\Python27\Lib, but that didn't help either... is your code somehow incompatible with 64-bit Python or wxPython maybe?

[Derakon]

No, I'm running 64-bit Python myself, so that's not it.

My Python is running out of /Library/Frameworks/Python.framework/Versions/2.7. In the lib/python2.7/site-packages directory is a file "wxredirect.pth" which points to /usr/local/lib/wxPython-2.9.4.0/lib/python2.7. That directory in turn has site-packages/wx-2.9.4-osx_cocoa/wx, which has the actual wxWidgets modules. There's no wx.py as far as I can tell; the __init__.py does the appropriate package setup.

Dunno, man; something's screwed up with your install.

EDIT: noticed that you were using Windows-style paths there, not Mac-style. I just tried running it on a Windows box and it complained about wx.BG_STYLE_PAINT not existing. So there may be some version mismatches here. That computer had wx version "2.8.12.0 (msw-unicode)". My development computer has version "2.9.4.0.b20120530 osx-cocoa (classic)". So make certain you have the right version of wxPython installed; you may need to use an unstable/development build.

[ekolis]

Well, I installed the unstable version and it still didn't work... I'll try reinstalling Python from scratch!

[ekolis]

Yay! Now it works!

edit: well, sort of - doesn't seem to be responding to keypresses! :P

[Gorbad]

I just tried running it on a Windows box and it complained about wx.BG_STYLE_PAINT not existing. So there may be some version mismatches here. That computer had wx version "2.8.12.0 (msw-unicode)". My development computer has version "2.9.4.0.b20120530 osx-cocoa (classic)". So make certain you have the right version of wxPython installed; you may need to use an unstable/development build.

I tried this on a Linux machine, and it also complained about BG_STYLE_PAINT, which is indeed not in wx 2.8.x. It worked (sort of!) for me when I replaced BG_STYLE_PAINT with BG_STYLE_CUSTOM in ./gui/wxPyrel/mainFrame.py.

[Derakon]

Glad to hear progress is being made! Sounds like I chose a very novel style for the main window. Perhaps there's a more compatible way to do that.

ekolis: try using the number keys along the top of the main island. The numpad keys only work if numlock is off. There's a list of all currently-accepted commands in userCommand.py; the keys that map to those commands are in gui/wxPyrey/keymap.py.