Forums
| ArianeSoft - Programming and development for Windows and Windows Mobile :: Forums :: PPL - Pocket Programming Language :: Code sharing |
|
<< Previous thread | Next thread >> |
| Component Classes? | ||
| Go to page [1] 2 | |
|
Moderators: kornalius, bmanske, PointOfLight
|
| Author | Post | ||
| Donone |
| ||
 Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Attached is a StatusBar Class file and a test program with mouse usage to illustrate. It is not complete but shows the principle. The statusbar has four panels, two grey would normally hold a legend and the white, varying values from the external program. It should be possible to vary the colours externally etc. The shapes are plain corners etc but could presumably be enhanced. As a newbie I am nervous that I am re-inventing a square wheel and this is all very obvious to everybody (except of course a newbie) and you use such things every day. The aim was to produce a Class of a 'control' (loose) that does not exist and be able to set properties and action methods, much as one would with a TClass of something. Any shape or complexity should be possible and any number of each can be instatiated. The principle, is to produce a sprite without having to do so in advance (on the fly), (thanks to zehlein for showing me how to do this). This is then placed within a class structure, with its own spriteproc and individually setable properties, as one might do in Delphi. (Do not be fooled by that statement, there is no comparison, but I can see uses for this principle of encapsulation of 'controls' and their properties/methods... at least for me. There are comments, some of which ask questions of the bits that gave errors if the // is removed. There are also questions about how to do a particular thing, which might enhance the principle. If anybody can assist me with perfecting those things I would be very very grateful. If this is re-inventing... please also let me know not to waste any more time, (but it was good for learning), I can take it  For my own use I would envisage making these controls and keeping the Classes in a library of #includes.  1193853831_231_FT0_status.zip[EDIT] The problem of ID being transferred to SpriteProc$ is now solved by using SpriteData. I don't know how to post a new version though. [ Edited Wed Oct 31 2007, 03:02pm ] You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
  Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | Hi Donone, this is a good starting point, thanks for sharing. Why FreeObject won't work I don't know but free() seems to work fine and is also ok with objects I think. The text1 proc does not render to the screen because it is called only once when you set the text in WinMain. g_textout should be used somewhere in the GameProc's WM_Paint section to make sure it renders everytime the screen gets painted. your code g_textout(NULL, t1$, DVT_CENTER, xx$, yy$, g_rgb(164, 164, 164)); seems to try to render without a font loaded (NULL) - to use it you will have to call a G_LOADVGAFONT before. The one solution I see for the textoutput is to render text directly to the dsStatus sprite's surface. There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Thanks for coming back on this zehlein. Perhaps kornalius can answer the first part about Free(). It is essential that the text is part of the status bar. The text would not usually be fixed when instantiated, but via method later. It must therefore render as part of the sprite not as a separate bit tacked on in the main program, to retain encapsulation. The sprite surface is always set to the size of the control being produced, The text once set will modify the drawing stage. I will experiment with text to that surface, which will essentially mean the sprite will be auto 'redesigned' and re-'newsprited' when it is changed, except its position. I shall do that today. I had a problem with the colour only rendering as black and the statusbar disappeared (something to do with colormask, I didn't understand). May be the text is invisible? The call to oStatus.top$(2) at the bottom of the main program said that Top$ wasn't defined, which I didn't understand. Version 2 identifies the statusbar correctly on clicking. 1193897287_231_FT7445_status2.zip You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | The reason for the errors on Text1 and Top calls resides in your class definition yor code: public proc Text1(t1$) should rather read: public proc dsStatus.Text1(t1$) In the Top declaration you missed to add the word public Another unsolved problem occurs with trying to create a struct with: Struct(sp$,TSprite); As far as I see TSprite is not declared in classstatus.ppl Another solution to your textoutput problem might be to create additional sprites that hold the text rather then rendering the text directly to the statusbar's surface. You could place them on the right place and when the text would change you could simply delete the old sprite and get a new sprite created. Keep on coding!  There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Thanks for your continued assistance zehlein. Last bit first, wonderful idea to overlay a text sprite rather than keep auto redesigning. I'll get onto that! TSprite is already defined somwhere as the sprite structure. That part works OK and is shown in v2 posted earlier. Your first point, regarding the declarations... I obviously mistakenly thought that because they were declared within the class, your definition wasn't required, only if forward declared (outside the class structure). I presume then that I can use 'self' and will try that. I dislike using the declaration inside the declaration. I know self is the same but somehow it doesn't feel so bad. I am also pleased that this doesn't appear to have been a total waste, or you would have been honest and said so. I'll try these things out now. [EDIT] Just tried self and also dsStatus.top but 'self' doesn't work, dsStatus does. I don't understand why dsStatus must be declared inside itself. As soon as I changed it I got a colour problem again and the grey has changed to black on black, without me seeming to do anything. Any ideas please? [EDIT] Colour solved! [ Edited Thu Nov 01 2007, 06:54am ] You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | the $ sign makes a variable out of say oStatus.Text1$ wich is by definition a procedure. The right usage therefore would be oStatus.Text1("Donone rocks!"); oStatus.Top(200); There has to be a redrawing feature embedded to the class, otherwise a statement like oStatus.Top(200) won't show an effect. But you surely are working on this... Btw, if you got an ICQ account send me a pm so we can have our discussion on this basis, if you like. There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | I value greatly your assistance in this, thank you. I do not have an ICQ account, have never used it and don't really know how to or what it is. Is it likely then that members of this forum will get upset at the length of this thread? My interest is that anybody like me might learn from the 'conversation' if it is agreeable to you. I presume this ICQ thing must be private. I have managed to make the external change to property 'Top' work in the attached version. I suspect though that you are right about a repaint because properties Left, Top etc only move it, but others may require more. Self doesn't work and I don't know why. 1193916424_231_FT7445_statusv3.zip You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | ICQ is a widely used internet chat protocol. I don't think someone will get upset by this thread. Who is not interested can safely ignore it But communication is a bit faster via chat, that's why I was asking, so never mind. There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | I shall look into ICQ for future use, so far I seem to have discovered that it is almost like instant conversation, much better for something long and drawn out. To consolidate excluding the text issue which is in progress, the remaining questions seem to be... 1. Regarding the following declaration:
proc dsStatus.Top(value$)
Why does what amounts to a Private procedure allow access from outside? It works with or without the public nomenclature, which seems to suggest an encapsulation leak. Why does the declaration require dsStatus? In which case why does 'self' not work? 2. Why does oStatus.Top(2); not work in MainProc? Presumably the Class declaration is/must be Public. 3. Why doesn't FreeObject work in MainProc? [EDIT] Before trying the overlay idea I tried this as a property procedure in the class but got a runtime error (access violation).
public proc dsStatus.Text1(t1$)
[ Edited Thu Nov 01 2007, 10:40am ] You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | Donone wrote ... 2. Why does oStatus.Top(2); not work in MainProc? Presumably the Class declaration is/must be Public. [EDIT] Before trying the overlay idea I tried this as a property procedure in the class but got a runtime error (access violation).
public proc dsStatus.Text1(t1$)
Make your object global after creation, then it will work in MainProc: global(oStatus$); Did you do a surface$ = SpriteSurface(sprite$); before trying to render to the surface? You will not get a text displayed with g_textout(NULL,...) because the first parameter is the font to use, it shouldn't be null. There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Thanks for coming back. My understanding was that if NULL is used the default system font is used, so I assumed this, because it worked when I originally put the line in the main drawing part (beginscene etc.) Stupid of me, knowing the Class had to be global but assuming oStatus would be also. Thank you. No I didn't do surface$=SpriteSurface(sprite$); I found SetRenderTarget(Surface$) and guessed it might allow me to go back to that surface, change it, then go back to oldSurface$. [EDIT] Surface$ was declared in the class as Private and so I assumed available anywhere within the Class. I think my problem is I don't think I understand surfaces and the sequence required to change from one to another. For example I don't see why having produced a new surface, the old one is reloaded then the new one 'attached' to the sprite. I have assumed that a sprite is controlled by the user program and points to a suface on which is rendered an image (bmp or drawn). When the sprite moves the surface is drawn on the screen at the sprite coords. I therefore see the sprite surface as re-drawable or exchangeable for another one. Also that the sprite surface as I have described moves over the main screen surface (don't know what it is called) like a transparent slide or something. If I have this concept wrong I would value your correcting me. I hope I am not taking too much of your time. [ Edited Thu Nov 01 2007, 12:52pm ] You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| PointOfLight |
| ||
  Registered Member #49 Joined: Sun Sep 17 2006, 03:02pmPosts: 1129 | NULL is acceptable for the first parameter of g_textout. I believe it uses a font called VGA.FNT at that point. As for the access violation, when did you assign oldSurface$ to anything? If I'm not mistaken, modifyng the code you supplied like this: public proc dsStatus.Text1(t1$) oldSurface$ = SetRenderTarget(surface$); g_beginScene; g_textout(NULL, t1$, 0, 1, 1, g_rgb(255, 0, 255)); g_update; SetRenderTarget(oldSurface$); end; should take care of the access violation error. I'm not sure this will accomplish yet what you want, but small steps... Eric Pankoke Founder Point Of Light Software http://www.polsoftware.com/ | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Thank you for that PointOf Light. I attach v4 for anybody who feels like answering the contained questions. zehlein has been very helpful today, I must have exhausted him. The reason I did not use oldSurface$ as you suggest is because that already exists (if that is the right term), from the original sprite creation. I think I assumed I would only need to swap the two existing surfaces without 'saving' because it pre-exists. As I said I don't really follow surfaces. I will try this though. 1193941414_231_FT7445_statusv4.zip[EDIT]You are correct, it did render the text. I assumed I would destroy the pre-existing oldSurface$. I need to find out about surfaces somewhere. [ Edited Thu Nov 01 2007, 02:38pm ] You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Text now sort of working but cannot clear before overwriting. I shall now try to solve some of the problems. Thank you both for you help today. 1193943817_231_FT7445_statusv5.zip You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | Donone wrote ... zehlein has been very helpful today, I must have exhausted him. Well no, I feel rather not exhausted, it's just that there is some sort of daily kids routine to be done. But now they are sleeping There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Usually after kids routine comes wife routine. My kids left home many years ago so I don't have those routines. v5 I think indicates the state of play and the remaining problems. Some of the surface cures with help from you and from PointOfLight have been effected but without me fully understanding. I am concerned that although the default for methods is Private, leaving public off still permits access from outside. If you do look at v5, you will see that several clicks on the screen area will change the text on the panel but I have been unable to clear previous text before writing new. Please do not feel in any way obliged to give further of your time, just because you have started. You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| PointOfLight |
| ||
| Registered Member #49 Joined: Sun Sep 17 2006, 03:02pmPosts: 1129 | Let me see if I can give you at least a brief explanation of surfaces. A surface is basically a drawing area. The main GameAPI window has two, each sprite is associated with one, and you can create surfaces independant of either the main surface or any sprites (ie: the CreateSurface function). The purpose of surfaces is to provide a method for double buffering, which allows you only to draw the main surface once during an update, so animation and the like doesn't appear choppy and so that you don't see things actually being drawn to the screen one at a time. As I said, each sprite has a surface. However, just drawing to that sprite's surface won't necessarily show a change to your application's display. At some point, that surface needs to get written to the BackBuffer, which is the buffer that ultimately gets displayed to the screen at the end of the GameAPI's draw routine. Functions like RenderSprites accomplish this. Also, as previously stated, you can create your own buffers independant of the main screen or sprites. To draw to these surfaces, you use the SetRenderTarget function, as you discovered in your coding. However, where you're missing the connection is that the return value of SetRenderTarget is the last surface that you passed to SetRenderTarget, or the BackBuffer if you've never called SetRenderTarget. That's why it's always a good idea that if you're going to call SetRenderTarget, capture the return value and pass that back to a subsequent call to SetRenderTarget. That should keep all your surface drawing straight Now, if you have an "offshore" surface as it were that you needed rendered to the backbuffer, you can use one of the provided DrawSurfaceXXX functions for this purpose. Finally, if you need to update the backbuffer to the main screen by hand, that's what the g_update function is for. Hopefully this sheds a little bit of light into the world of surfaces for you. Eric Pankoke Founder Point Of Light Software http://www.polsoftware.com/ | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Thank you PointOfLight, for your generosity with your time. I am deliberately replying before reading because I want to read slowly and digest. By the way PointOfLight and zehlein, as you will see from another thread, I have been 'trumped' in timely fashion by kornalius. I wish we could have completed, but it does sort of work. I have learned a great deal from this exercise and am about to learn more about surfaces. Can anybody see a different use for this (when perfected) other than the original aim, (perhaps easy encapsulated sprite control) please say because otherwise it is really academic now and doesn't have a purpose other than a learning exercise, which I am always game for. I look forward very much to the new TClasses in PPL2. You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| PointOfLight |
| ||
| Registered Member #49 Joined: Sun Sep 17 2006, 03:02pmPosts: 1129 | Keep in mind that what Alain is doing is turning Windows GUI development into an object oriented environment. I don't believe this will have any impact on the GameAPI at all, so I'm sure there still could be some use for OOP in the GameAPI world! Eric Pankoke Founder Point Of Light Software http://www.polsoftware.com/ | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | Thank you PointOfLight, your info on surfaces is very enlightening. When it has sunk in and I look at some of the functions, I suspect it may raise one or two questions, which I hope I can come back on. My intention originally was of course to try to overcome one or two areas of a windows program that required OOP controls not available. In a sense it could only mimic. But yes I think the GameAPI might through encapsulation in classes benefit from this. Perhaps after all it may be worth persuing. Thank you for your wisdom! You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | I don't know if this continuation should be in this thread or what to do about it anyway. I have a question about the return value of SetRenderTarget. In my v5 sample I had already used oldSurface$ and fed it back at the end.
Surface$=NewSurface(x1$, y1$);
I then needed to draw again so I simply did this...
surface$=SpriteSurface(Sprite$);
on the assumption that olsSurface$ remained from the previous time and further assumed that by doing as you suggested I would wipe it 'or something'. Since I was wrong, I still have a little hole in my understanding because I presumed once made these surfaces remain until deleted, (possibly as a bmp) so my next thought would be should I use oldSurface1$ but this is discounted by the fact that it worked anyway with no apparent side effects. BTW I can't see why the line above starting // doesn't wipe the previous, now why the alignment didn't work when I selected DVT_CENTER. With a little more understanding I might be able finally to produce a short tutorial with pictures for anybody coming later who doesn't find your description or still has questions. [ Edited Fri Nov 02 2007, 02:50am ] You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | @zehlein if you are still interested. I am now working on this to exclusively OOP GameAPI not windows. I followed your suggestion about overlaying the text as below, but as usual without knowing what I am doing (clear, from the fact that it doesn't work).
f$=G_LoadFont("Arial",6,RGB(0,0,0)
,FONT_NORMAL,-1);
Any thoughts? I can't figure how to stick the two sprites together. You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | Good morning Donone , -> on the assumption that olsSurface$ remained from the previous time and further assumed that by doing as you suggested I would wipe it 'or something'.<- Every variable that is not declared global will be "lost" (i.e. it doesn't hold a value anymore) once the program leaves the procedure/function where it was used. That's why your OldSurface$ won't work. You will have to "reload" it with OldSurface$=SetRenderTarget(surface $). Don't get fooled here, OldSurface$, Surface$, Sprite$... are all just variables that hold the handle/address oft the "physical" object in the computers memory. By doing a OldSurface$=SetRenderTarget(surface$) for the second time there won't be anything newly created. Let me have the recent version of your code to assist you with the code in your previous post, I can't tell what it does because I have no idea what value the vars hold. Keep on with your work! There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | It's good to see you back zehlein. Thanks for the suggestion to continue. Heartened! Thank you for reminding me about the variables, with PPL for some odd reason I 'feel' things don't work the same and I don't know why (almost as if kornalius has invented a new way), of course they work the same. I must say that now I have got going I feel PPL to be very exciting. v6 attached. Click the blank screen area a couple of times and this shows that the setting of properties in Mousedown works. There are questions in the comments and in progress bits. A lot of tidying afterwards also. You will see text problem with YES NO superimposed. I cannot clear it first with spaces (seems odd) and I cannot find a function to do it. You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | ... forgot the attachment!? There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | I must be losing it. Sorry. v6 shows the problem with using spaces to wipe text (or not ) with the old code.Waypoint is the same everything except for the text drawing now trying your suggestion of overlaying another sprite, but I can't glue them together nor can I see the new one. The name change is because I have now moved away from components for windows and adapting this for Game only and you caught me in the middle. 1193998510_231_FT7445_statusv6.zip 1193998510_231_FT7445_waypoint.zip You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| zehlein |
| ||
| Registered Member #30 Joined: Tue Sep 12 2006, 03:00pmPosts: 449 | Well, it kind of works. Two little flaws: * cts$=g_CacheText(f$,t1$, 1,1); creates a 1x1 pixel surface, you wont see the text in it for sure * MoveSprite(s$,0,0); Moves your textsprite to the upper left corner of the screen - you should use the coordinates of your statusbar here Hope that helps! There is a crack, a crack in everything. That's how the light gets in. (L. Cohen) | ||
| Back to top | | ||
| kornalius |
| ||
  Registered Member #1 Joined: Wed Apr 19 2006, 08:25pmPosts: 2783 | Donone, keep up the good work. I am planning on including classes for the GameAPI too, sound, sprites, surfaces... The only downside is that it will slow down the execution speed. It will provide easy programming but lower speed. I expect to have come up with more optimizations for the object-oriented engine by the time version 2.0 comes out. Regards, Alain Deschenes President and programmer ArianeSoft Inc. (http://www.arianesoft.ca) | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | @kornalius: You seem to be up early . If you are doing the classes for the GameAPI would I not be wasting my time trying to do the same (especially when you have much greater skill/knowledge and probably underlying windows technology to call upon)? Thanks for your keep going comment, which seems to suggest the opposite. @zehlein: I like your humour regarding 1,1. I misunderstood that as being x,y, i.e. the start position and also I thought I was using coords (0,0) relative to the Class because I am within it. I will review to see what you are suggesting. Thanks You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| Donone |
| ||
| Registered Member #231 Joined: Fri Jan 12 2007, 10:17amPosts: 626 | @zehlein: Well I have finally caught up with you. It seems I chose the right function (cacheText), I have enlarged the text sprite from negligable to 49,13 (I'll use the proper variables for the panel size/position later ) and of course the 0,0 should have been Left$,TopS. It works 'appears' to work but doesn't. The text appears on the panel until the panel moves, then it shows that it used the panel coords but on the screen. I still cannot see how to join the sprites i.e. to move together. [EDIT] To be honest, it would seem a lot easier to me to be able to use my original method of text i.e. v6 but to find out how to clear the original before writing the new. At least the text was on the panel proper. Do you know how I can clear the text? [ Edited Fri Nov 02 2007, 08:12am ] You only stop learning when you die. Sometimes I think I am dead http://www.don-simmonds.co.uk | ||
| Back to top | | ||
| Go to page [1] 2 | |
Powered by e107 Forum System