Gpc

gpc@gnu.de

5400 discussions

Re: Objects question...
by Peter Gerwinski 04 Sep '97

04 Sep '97

According to Orlando Llanes: > > I'm curious about something with objects as it will affect the game lib. > What I need to know is how objects work at run-time. Each instance of each object has an implicit "vmt" field which contains a pointer to the "virtual method table" where the addresses of all virtual methods are stored. GPC produces inline code to initialize the vmt immediately before a constructor is called. (BP does the assignment inside the constructor instead.) When a virtual method is called, the program dereferences the vmt field, and so on. > Is there a way to > create an object so that it will be loaded only if allocated with "New"? In > other words, is there a way to keep the code for the object on disk until > it's needed, and removed form memory when not? Write a constructor that fetches all needed data from the file when the object is `New'ed; if you want to keep the stuff in the file current, write a destructor that writes everything back to disk when the object is `Dispose'd. (* BTW, this has nothing to do with the internals how objects work at run-time. ;*) You are obviously writing a memory manager to keep the amount of RAM your program uses small and to use the disk instead. On UNIX-like platforms you don't need to do this because the operating system does it for you. Just allocate as many MegaBytes as you need; if this exceeds your physical RAM the operating system swaps out the unneeded parts automatically and restores them when they are needed again. Your application does not even notice this. Have fun, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BUG !
by Peter Gerwinski 04 Sep '97

04 Sep '97

> There is a bug !!! > > in your Web page... > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_56.html#SEC93 > "See See section How you can contribute to GNU Pascal for details." > --^ :-) We know. In newer versions of the documentation this is already fixed. The problem is that the GNU "Texinfo" format which is standard for documentation of GNU programs requires a particular wording. Thanks for the report, anyway. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

BUG !
by Stéphane 04 Sep '97

04 Sep '97

There is a bug !!! in your Web page... http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_56.html#SEC93 "See See section How you can contribute to GNU Pascal for details." --^ Stephane From The Kilobug Team.

1 0

Objects question...
by Orlando Llanes 03 Sep '97

03 Sep '97

I'm curious about something with objects as it will affect the game lib. What I need to know is how objects work at run-time. Is there a way to create an object so that it will be loaded only if allocated with "New"? In other words, is there a way to keep the code for the object on disk until it's needed, and removed form memory when not? See ya! Orlando Llanes

1 0

Re: gpc objects
by Orlando Llanes 01 Sep '97

01 Sep '97

From: Paul Doerwald <clavicle(a)niagara.com> >It's something I'd be interested in doing, preferably with someone else, >because I'm not a stellar pascal programmer. I have a fair bit of TP >experience, and a reasonable grasp of programming language principles. Is >there someone who would join me on it? I'll be helping out too. See ya! Orlando Llanes

1 0

Re: gpc objects
by Paul Doerwald 01 Sep '97

01 Sep '97

>> I think a good documentation, explaining all gpc functioning, will be >> very useful to all pascal programmers that want to migrate to gpc. > I agree. Anybody interested to help writing such a thing? It's something I'd be interested in doing, preferably with someone else, because I'm not a stellar pascal programmer. I have a fair bit of TP experience, and a reasonable grasp of programming language principles. Is there someone who would join me on it? ----- Paul Doerwald clavicle(a)niagara.com www.niagara.com/~clavicle

1 0

Re: gpc objects
by Peter Gerwinski 31 Aug '97

31 Aug '97

According to Fausto Iannuzzi: > > I know gpc has both functions and operators overloading that are missing > form extended pascal It has operator overloading; function overloading is planned but not yet available. > because it does not support OOP and are also missing > from borland pascal and delphi (2.0). This has nothing to do with OOP. > From which standard they have been > implemented? >From Pascal-SC (PXSC). See http://ma70.rz.uni-karlsruhe.de/~ae25/iam/html/language/xsc-sprachen.html http://wwwma.rz.uni-karlsruhe.de/~ae08/iam/html/language/pxsc.html > Is there in gpc other OOP stuff that is not present in BP ? You can mix methods and data fields: Type MyObject = object a: Integer; Constructor Foo; b: Real; Destructor Bar; c: Char; Procedure Baz; d: ^String; end (* MyObject *); > I think a good documentation, explaining all gpc functioning, will be > very useful to all pascal programmers that want to migrate to gpc. I agree. Anybody interested to help writing such a thing? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

gpc objects
by Fausto Iannuzzi 31 Aug '97

31 Aug '97

Hi! I know gpc has both functions and operators overloading that are missing form extended pascal because it does not support OOP and are also missing from borland pascal and delphi (2.0). From which standard they have been implemented? Is there in gpc other OOP stuff that is not present in BP ? I think a good documentation, explaining all gpc functioning, will be very useful to all pascal programmers that want to migrate to gpc. bye, Fausto. Reply addresses: fausty(a)itb.it (primary - local provider) fausty(a)peacelink.it (gateway - please no files here) Homepage: www.itb.it/users/fausty/welcome.html

1 0

Re: bwGraphics Library
by Orlando Llanes 28 Aug '97

28 Aug '97

From: Bernhard Tschirren <bernie(a)icenet.com.au> >ZIP (~80KB). NOTE: As I meantioned to Orlando, the source will NOT compile >with the latest version of GPC - but it will compile with the NEXT update >(whenever that is released!) Which reminds me, what directory do I rebuild the source from for GPC? >It WAS working with BOTH. I used the protected mode bank swithing (VBE2), >if needed. I think that code is still in VESA.PAS. I also had VBE2 linear >frame buffer modes working. You have to think about the loud majority that don't have VBE2 tho. Not everybody has the UniVBE driver, think of how upset the person would be if they bought your game or application only to find out that they have to pay more (especially when they consider that they've spent enough as it is). Another thing is that VBE2 hasn't caught on to Video Card BIOS's yet, not everybody has a Matrox Millenium II. My point is that you can support it as an enhancement, but your libs should not depend on the driver being VBE2. Disregard this if you support direct bank switching for VBE 1.2+ >I have done it so that I have the best of both worlds! The VGA.DRV is in > ... >first attempt at explaining it: It is a nice scheme, but do you plan to make your lib portable? I ask because loadable drivers may not be portable to other platforms or OS' >This may sound confusing but it is NOT, its the HEART of my engine - and I > ... >of doing stuff across a network, however I have not thought much about that One of my major goals is simplicity. I aim for the beginner (hence the API being as it is), the novice, and the advanced user (exposing the virtual screen buffer for custom operations). >Now, back to the OBJECT problem. One of the FunctionNr's provided by the > ... >this will become clear - its very simple (for me anyway)! If you go with the COM architecture, I'd suggest writing a wrapper API to target the users who want to focus on the algorithms rather than the coding, or for the beginners. Somethign else you should consider is how you plan to release the code, I noticed you have it under the GPL, it may be better to release it under the LGPL, it gives the user more flexibility on how they can use it, and also retains your copyright. See ya! Orlando Llanes

1 0

bwGraphics Library
by Bernhard Tschirren 28 Aug '97

28 Aug '97

This is primarily directed towards Orlando Llanes, but Im sending it via this list because I would like some input from other people. If anybody would like the -current- source code, please mail me. I will attach it as a ZIP (~80KB). NOTE: As I meantioned to Orlando, the source will NOT compile with the latest version of GPC - but it will compile with the NEXT update (whenever that is released!) At 16:58 27/08/97 -0400, you wrote: >> (VESA.PAS) is included, but completely OLD and NON WORKING! > Using Linear Frame Buffers? Or using bank switching? I was thinking of It WAS working with BOTH. I used the protected mode bank swithing (VBE2), if needed. I think that code is still in VESA.PAS. I also had VBE2 linear frame buffer modes working. >page, then it allocates a new page. There's something I'm curious about, >does your lib use a loadable device driver? I ask because I saw VGA.DRV If >it is, it may be a bad idea to use one because you're prolly better off >using objects. I have done it so that I have the best of both worlds! The VGA.DRV is in fact a loadable device driver (DXE) HOWEVER if you look at VGA.PAS (Source of VGA.DRV) you will see that it mostly a heap of communication routines using an INGENIOUS scheme developed by me (as fas as I know)! Below is my first attempt at explaining it: The device driver loads as a record (pre-initialised) which is defined in bwGLOBAL.PAS as "bwTGraphDriver". This record defines pointers to two routines - "ComHandler" and "ComRequest". ANYTHING and EVERYTHING (except drawing to the screen at this stage) is done using these two routines. Below is a small diagram which shows how it all works: MAIN PROGRAM DRIVER ComRequest -------------------> ComHandler ComHandler <------------------- ComRequest To communicate with the graphics driver, the MAIN PROGRAM calls "ComRequest(FunctionNr)" which infact points at the "ComHandler" on the DRIVER. Similarly, the DRIVER may communicate with the MAIN PROGRAM by calling its "ComRequest(FunctionNr)" which points to "ComHandler" in the MAIN PROGRAM. FunctionNr is just a constant that says WHAT should be done by the handler. A list of these can be found in bwGLOBAL.PAS. This may sound confusing but it is NOT, its the HEART of my engine - and I LOVE IT! This means that any driver could be extended to become PRINTER DRIVERS, etc. by setting up and handling extra FunctionNr's in the "ComHandler" routine on the DRIVER. Hmm, it also sounds a bit networky with all that "communication" and stuff - BINGO! It is also an efficient method of doing stuff across a network, however I have not thought much about that yet... Now, back to the OBJECT problem. One of the FunctionNr's provided by the standard driver is to return a pointer to the SCREEN OBJECT. So, the user can have direct access to the screen via this object. The code below shows how simple it is to do this: Var Screen : bwPBaseBitmap; { Screen Object } Begin Error := ComRequest^(bwComGetScreen,@Screen); If (Error <> bwErrAllOK) Then Return(Error); End; This above code is actually never needed because it is automatically done when you initialise a graphics mode. The code for this is "bwGraphInit" in bwGRAPH.PAS. Therefore, the VGA.DRV file contains both the communication handlers, and the object definition/methods of the screen. If you take a look at the code this will become clear - its very simple (for me anyway)! The default screen/bitmap object is called "bwTBaseBitmap" and you can find the definition for it in bwGLOBAL.PAS. This object is overridden by "bwTBitmap8Bit" (bw8BIT.PAS) which implements 8 bit bitmaps in memory. In future, I will add other objects for 16, 24 and 32 bit bitmaps. The VGA driver (VGA.PAS) overrides the "bwTBitmap8Bit" object. The base screen object (bwTBaseBitmap) is set up so its easy to write drivers for harware accelerated graphics cards. So, a driver only needs to override the "PutBitmap" procedure on a board that supports hardware blitting. As a pleasant side effect, this overriding creates small driver files - Just take a look at VGA.DRV and VGA.PAS. If you have any more questions please mail me. Im happy that I can tell someone else my thoughts and ideas... ________________________ e-mail: bernie(a)icenet.com.au | _) | | ptschirrenb(a)cc.curtin.edu.au |___)ernhard |_|schirren tschirre(a)cs.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc