RPG Maker PY (RMPY)

[Blizzard]

You're not redrawing the map at all if you use sprites. You just set the proper pointers. With your method you always have to blit the whole thing each time you make a change.

[Ryex]

oh I get you, thing is that there is no shut thing as sprites in pygame. or there is but I can't use them in conjunction with the normal editor. If I make a game engine I'll be sure to keep this in mind.

also sprites come down to a blit anyway. how else would they get drawn to the screen surface?

when Pygame dose a blit all it dose it tell SDL to do it so it will be fast.

I just have to keep the number of blits I do each "frame" so to speak to a minimum. that means pulling from a pre rendered map if it hasn't changed. and when it dose change only draw the changed tiles. cache autotile patterns so they don't have to be redrawn. ect.

I also have to keep the size of the blit that GDI dose as small as I can because it is likely to be the slowest operation, probably slower than all the pygame blits together even with drawing the map for the first time.

[Blizzard]

I don't think you know what I mean. The way how RMXP works with this is just fine. You have a bunch of bitmaps and a bunch of objects that display those bitmaps (in RMXP's case sprites). You never do any blit operation, you just link the sprites with the bitmaps, i.e. sprites have a pointer to the bitmap they are supposed to show. You never have to use a blit operation for this, that's what I
meant. You just have a bunch of sprites that are used for display.
Sprites don't get blit to be drawn. A simply polygon drawing operation with 4 vertices and the proper UV coordinates is all you need to draw a bitmap from a sprite on the screen. Blitting is basically copying bitmap data which is never done or needs to be done here.

[Ryex]

such a method dose not exist in pygame. when you use sprites you still have to tell them to copy themselves to a surface other wise they never display.

[Blizzard]

By blitting? Wow, that sucks ass. No wonder it's slow.

[Ryex]

pygame isn't slow GDI is. GDI is windows internal drawing library the one wxpython hooks into. pygame uses SDL which is FAST. GDI has no notion of sprites only Blits
Pygame uses SDL which is a 2d frame buffer and while it can be used with pyopengl this isn't a stranded feature.

so blits via SDL it is.

[Blizzard]

I know what SDL is, thank you.
It's still a bit weird how it works. I'm used to direct OpenGL/DirectX processing and drawing of polygons so this seemed kind of a performance eater to me.

[Ryex]

I know what SDL is, thank you.
It's still a bit weird how it works. I'm used to direct OpenGL/DirectX processing and drawing of polygons so this seemed kind of a performance eater to me.

didn't mean to offend Just rationalizing

but ya I was surprised when I looked into Pygames sprites too.

basically you create a sprite. make sure that Sprite.image is a surface containing the graphic to draw and Sprite.rect is a rect for the position.
then you add the sprite to a spritegroup and call Group.draw(surface) where surface is the surface to draw the sprites in the group to (normally the display screen)
and the docs say the Group.draw does blit operations so ya.

[Blizzard]

You didn't offend me, that's what the smiley was there for.

[Ryex]

well after getting out from under the pressure of a chem exam a bunch of homework and some sleep problems causing me to miss a bunch of classes for about two and half weeks. I started work again.

tonight I added a AutotilePattern method to my new cache class written for Pygame. it creates an auto tile pattern and stores it so that it doesn't need to be redrawn. I also redid all the dialogs to display properly on all platforms. and I fixed the new project dialog to create the project folder instead of requiring that it already exists.

[The Niche]

Go Ryex! Dammit, I had a cool idea and I can't remember it. Fuck.

[Valath]

Seph is an idiot.

Well, yes, sir. You, Kefka and I had come to that agreement.


I was wondering, would creating/customizing new Stats, besides the default 4-6, require the editing of default RTP scripts?

[Blizzard]

I can't wait until the FF sequel is released where I am the final boss.

[Fantasist]

It's still a bit weird how it works. I'm used to direct OpenGL/DirectX processing and drawing of polygons so this seemed kind of a performance eater to me.

@Ryex: On that note, why don't you look at pyglet? It's based on OpenGL, and should be a faster. But I guess it's too late for that now, considering you've done a lot already. Still, thought I had to mention it.

EDIT: Just took an hour to read through the entire topic. I see switching to pyglet at this point might not be a good idea, sorry ^_^'

I have an idea to contribute.

Issue Title: Custom Event Commands
Description: Let's say I want to make a door event. I have to do the following:

@> Set Move Route (door): <change sprites to animate event>
@> Set Move Route (player): Move towards the door event (in either of 4 directions)
@> Wait For Move Completion
@> Teleport

Suggestion: If I could group some event commands into "Custom Events", it would make my life easier. In the above case, I would group the first 3 commands into the custom event "Open Door" and the result would be:

@> Custom Event (Open Door)
@> Teleport

Also, it would be great if custom events had customizable number of arguments. Something along the lines of:
Add Parameter... -> Type out name of parameter

Each custom event needs to have a list of parameters. The parameters need not even be drop-down lists or anything complex, just text boxes will do. You will have to find a way to transport these parameters to the event commands contained by the custom command. Something like the $1, $2, etc. in regular expressions.

EDIT 2: Wait, common events already do the grouping thing (thanks SRK for reminding me), but passing parameters qualifies as a new new feature, I guess

[The Niche]

That sounds like an awesome idea.

[Starrodkirby86]

That suggestion reminds me of Common Events. Though it probably more functionality than a Common Event would, I would guess. xD

But any macro shortcut idea is always a valuable one. :V

[Fantasist]

@SRK: You totally totally pwnd me >.< I'm such an idiot. I guess I'm only good at scripting, huh? Though, common events won't let you add parameters every time, so that would qualify as a new feature. This basically means any script calls required by custom scripts will effectively become event commands.

[Blizzard]

That's what variables are for; they can act as parameters for common events.

[Ryex]

event building macros.... HOLLY!  

they would be like event templates. and the event editor would have an interface to them. oh thats a awesome idea!

as it stands my current idea for an event editor is this.

Spoiler: ShowHide

@Fant  thanks for pointing out that library I didn't even know it existed. but alas, after quite a bit of research I find that there is no working method of getting pyglet to draw inside a wxwindow or even a wxglcontext. there are at least 7 attempts in the mailing lists and it only works truly works on widows. the linux version barely worked. and no attempt at an osx version exists.  true I could use PyOpenGl but it doesn't have the sprite capability of pyglet. If I wanted to I suppose I could learn OpenGl and create my own sprite class. but I really don;t feel like it. a OpenGl version of the map display could be a feature in a latter version easily. the plugin architecture easily allows for it.

[Fantasist]

That's what variables are for; they can act as parameters for common events.

haha, yeah... *facepalm*

@Ryex: Too bad then. Whatever suits your needs then (I wonder how RMXP does it...)