Day 1 was a bust but still hopeful
Deathworks on 2007/09/03 10:26
of Deathworks
Hi!
Yeah, even though I felt a bit better, yesterday I was simply too tired to get far. In addition, I also ran into what I now remember to have been an issue back when I first met wxWindows as well, namely wxClientDC. Somehow I can't get these beasts to work.
Fortunately, in the end I was able to get cooperation out of wxPaintDC and even found a solution where its placement in the parent-child hierarchy wouldn't pose a problem (basically, my design requires it to run as a child of the main window, but all the interaction (= drawing) is actually done by changing children of the main window).
And I even figured out how to force 640x480 screen resolution (although setting the frequency doesn't seem to work properly for me). Oh well, at least I have true full screen now.
I have looked at Skellington. I will definitely not use its run.py example, because it doesn't seem to really give me control over where a file is opened within the relative tree.
Instead, I am using something along the following lines:
try:
DW_Const_Root_Dictionary = os.path.abspath(os.path.dirname(__file__))
except:
DW_Const_Root_Directory = os.path.abspath(os.path.dirname(__name__))
DW_Const_Code_Directory = os.path.join(DW_Const_Root_Directory,"code")
execfile(os.path.join(DW_Const_Code_Directory,"constants.py"))
Theoretically, that should give me the same portability as the Skellington package has (wxPython used a small function hidden away in their Main.py in order to handle the conversion, so it looked as if they didn't do it).
However, __name__ NameErrors also when I start things directly (^_^;; (everything worked fine when I pressed F5 while editing things in IDLE). I think, if I used "." instead of __name__, shouldn't that do the trick? I will have to test that once I get home.
Still, despite the various setbacks (and the fact that I am currently house-sitting over at my parents' place because they are expecting some furniture parts to be delivered this afternoon), I still believe I can make it.
With the main menu (at least graphically) working as planned, I have effectively tested all graphics related commands I need and keyboard controls are also working fine (while I will try to add pad control, in case of emergency, keyboard would be sufficient).
The next major task is mainly data management, data loading and data saving. The basic routines in Python are known to me, and my knowledge concerning them should be sufficient to handle things.
The only thing I am a bit worried about is whether to use 'b' mode or not. The manual says that the standard build of Python wouldn't require 'b' mode for text, handling any correctly and automatically converting them to Python's native format. Even if that wasn't the case, if readlines() was able to identify lines correctly, I should be fine for nearly all text data since I don't need to know what each line ends with (there is just one exception).
Otherwise, I hope that I can use walk in some way to fix things up (using it to read all files in normal mode and then write them back in b- mode or something like that).
Besides such portability questions (and the question if the MIT is completely sufficient a license and how to use it), the only difficult thing I will probably come across is putting text messages on the screen. There should be some wxPython classes and methods helping with that, but that may require some fine-tuning.
Well, I guess what Tuesday will be for :) :) :)
Ah, I wanted to share at least a screenshot of the main menu as it is now (graphics will be refined on Wednesday), but Pyweek wouldn't allow me to upload stuff from my parents' computer (could be their firewall; I tried doing things using Firefox and IE, but I always got an unclassified error and the program pointing out that the field 'file' (the one connected to the browse button) was required. Once I am back home, I will check whether things are as bad on the university computers.
Okay, the title of the game is not really subtle, but I think it is okay :) :) :)
Deathworks
(log in to comment)
Comments
richard on
2007/09/03 11:09:
paulreiners on
2007/09/03 14:25:
Deathworks on
2007/09/03 14:46:
Hi!
Paulreiners: I am sorry to disappoint you, but I am not using PyGame at all, instead relying on wxPython, which is something completely different. And I don't think it would be a good idea to combine the two.
I had a quick look over at the PyGame docs, and I guess you will have to do something using a Font:
http://www.pygame.org/docs/ref/font.html
Look at the Font.render method, there are some instructions. Beyond that, there is no help I can give, sorry.
Deathworks on
2007/09/03 15:02:
Hi!
I just had one more look at the Font reference.
Actually, the routine you will need to use will be somewhat similar to what I will eventually need to implement myself, if you wish to do longer (multi-line) texts.
First, divide the text into pre-defined lines (that is, divide it into strings that end with \n). Remove all the \n in the new strings! You will have to process each of these strings separately.
Define variables, like x and y, denoting the upper left corner of the inside of your message box
Entry Point: Use the Font.size method on the newly created string you are currently working on, starting with the first of the partial strings.
If the return value of Font.size is less than the inner width of the message box, you can now render that string at (x,y) using Font.render. Increase y by Font.height. Then move on to check the size of the next string. (until you are just above the bottom of the message box :) :) :) )
If the return value was greater, divide the return value by the inner width of the message box and mutiply the result with len(string). The integer of that result can now be used as a pointer into the string. Search for a ' ' in that area and create a new string (splice?) starting from string [0] up to but not containing that space. Remember the position.
Use Font.size on the newly spliced string. If it is less than inner width, search the next space to the right and check whether that would still be less than inner width. If it is more than inner width, search for the next space to the left. Repeat until the result changes. You may have to look for more neighboring spaces until you get the ideal result (less than inner width, but as close as possible).
Render that final spliced string using Font.render. Add Font.height to y. Create a new string starting from the position after the space ' ' where you made the cut (I suggest checking for multiple space and skipping all). Return to Entry Point with that string.
There are still a bit of details you would need to do and some fine-tuning, but I think that should get you on the right path for a simple word-wrapping routine.
Good luck!
paulreiners on
2007/09/03 21:01:
richard on
2007/09/03 11:08:
That looks awesome! :)