Re: [fpc-devel] sdlgraph, pre-alpha
On Wednesday 22 August 2007 19:18, Micha Nelissen wrote: > Michael Van Canneyt wrote: > >> Why is calling via a procvar very much slower than a normal call ? > >> It's just an extra memory fetch (hopefully in cache) ? > > > > Jonas meant that each pixel is drawn separately. The procvar is not > > the issue. > > Before me going too far in unknown territory, but isn't that the > basis for any software implemented graphics routine: drawing pixels ? According to Michael Abrash: No, it's not. Linedrawing is more like it. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling on OSX and case sensitive filesystems
Jonas Maebe wrote: On 23 Aug 2007, at 00:00, Marc Weustink wrote: Target by target and tonight I came to the last: OSX. And there I noticed that the ppcppc 2.1.5 compiler stopped searching for Lower/Uppercase unitname variants, so it cannot compile my lazarus sources anymore (while 2.0.4 happily does) Is there a way, flag, option, define, whatever to turn this behaviour back on ? No. The whole case sensitivity handling in the compiler is pretty broken by design currently, as it's hardcoded per OS based on the most common situation under said OS and not configurable in any way (although most OSes nowadays support case insensitive, case-aware and case-sensitive file systems). Yes, i can imagine it popping up more often. Your issue is caused by the implementation of a directory cache in the compiler since 2.0.4, which for systems defined as case-aware did not keep track of the original file name casing. Your issue is probably fixed/worked around in 2.3.1, but that change will not be merged back to 2.1.5, because it was quite invasive. It will however be in 2.2.2 OK, I can live with that. I'll stick to 2.0.4 on osx for a while then. Thanks for the explanation. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling on OSX and case sensitive filesystems
On 23 Aug 2007, at 00:00, Marc Weustink wrote: Target by target and tonight I came to the last: OSX. And there I noticed that the ppcppc 2.1.5 compiler stopped searching for Lower/Uppercase unitname variants, so it cannot compile my lazarus sources anymore (while 2.0.4 happily does) Is there a way, flag, option, define, whatever to turn this behaviour back on ? No. The whole case sensitivity handling in the compiler is pretty broken by design currently, as it's hardcoded per OS based on the most common situation under said OS and not configurable in any way (although most OSes nowadays support case insensitive, case-aware and case-sensitive file systems). Your issue is caused by the implementation of a directory cache in the compiler since 2.0.4, which for systems defined as case-aware did not keep track of the original file name casing. Your issue is probably fixed/worked around in 2.3.1, but that change will not be merged back to 2.1.5, because it was quite invasive. It will however be in 2.2.2 Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Uninstalling fpc in MacOS X
On 22 Aug 2007, at 23:36, Christian U. wrote: Is there an easy way to uninstall fpc in MacOS X ? Not really. An uninstall facility is a glaring omission in Apple's Mac OS X installer infrastructure (even though you can mark installer packages as "uninstallable" when creating them, there is no uninstall command to be found anywhere). I have installes an snapshot package from lazarus page with fpc 2.1.5. Type cmd-shift-G in the Finder, enter /usr/local/lib in the dialog box, and delete the "fpc" folder from the directory you end up in (you will have to authenticate as administrator to be able to do that). That will remove the bulk of the files. If you want, you can also delete these files (note that /usr/local/bin can also contain other files, so it's generally not safe to just delete that entire directory): /usr/local/bin/bin2obj /usr/local/bin/data2inc /usr/local/bin/delp /usr/local/bin/fd2pascal /usr/local/bin/fpc /usr/local/bin/fpcmake /usr/local/bin/fpcmkcfg /usr/local/bin/fpcsubst /usr/local/bin/fpdoc /usr/local/bin/fppkg /usr/local/bin/fprcp /usr/local/bin/h2pas /usr/local/bin/h2paspp /usr/local/bin/makeskel /usr/local/bin/mkxmlrpc /usr/local/bin/plex /usr/local/bin/postw32 /usr/local/bin/ppcppc /usr/local/bin/ppdep /usr/local/bin/ppudump /usr/local/bin/ppufiles /usr/local/bin/ppumove /usr/local/bin/ptop /usr/local/bin/pyacc /usr/local/bin/rmcvsdir /usr/local/bin/rstconv /usr/local/bin/unitdiff Next, you can navigate to /Library/Receipts in the Finder and delete the fpc-2.1.5*.pkg file (replace * with the date of the snapshot your downloaded). It's also possible to automate entire process, but BE WARNED: I did *NOT* test the following, and an error in a command like that can result in many more files being deleted than just those you want to be gone. Proceed at your own risk. Executing the following in a Terminal window should do the trick (type the commands followed by "return"): 1) cd / 2) (make sure the entire following command is on one line; you will also be asked for your administrator password): sudo lsbom -pF /Library/Receipts/fpc-2.1.5*.pkg/Contents/Archive.bom | xargs rm -f Next, you can navigate to /Library/Receipts in the Finder and delete the fpc-2.1.5*.pkg file (replace * with the date of the snapshot your downloaded) -- same as in the first set of instructions. This second set of commands will leave behind a few empty directories, but all FPC-related files will be removed. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Compiling on OSX and case sensitive filesystems
Hi, For Lazarus development I share my lazarus sources on a nfs and samba export, so I have the same source tree for Win32/64/CE, Linux and OSX development. Samba is used for windows, nfs for the others. The last months I've been switching my development compiler from 2.0.4 to 2.1.5 Target by target and tonight I came to the last: OSX. And there I noticed that the ppcppc 2.1.5 compiler stopped searching for Lower/Uppercase unitname variants, so it cannot compile my lazarus sources anymore (while 2.0.4 happily does) Is there a way, flag, option, define, whatever to turn this behaviour back on ? Thanks, Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Uninstalling fpc in MacOS X
Is there an easy way to uninstall fpc in MacOS X ? I have installes an snapshot package from lazarus page with fpc 2.1.5. regards Christian ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
On 22 Aug 2007, at 20:59, Evgeniy Ivanov wrote: Hm... I've tried such thing: procedure sdlgraph_HLine(x,x2,y: smallint); begin SDL_DrawLine(screen,X,y,x2,y,255); SDL_Flip(screen); end; The same. I will try to find the true way, but I'm not sure that it can be without locking overhead. I reimplement Bar3d with adding locking - very quick. I think it is the fastest HLine implementation I guess the problem is that you blit the entire screen after every drawing operation. It will be faster when drawing lines at a time, but still slow. In theory, the flipping could/should be done from a separate thread, which only does the flipping once per vertical refresh of the monitor. I don't know whether SDL provides access to this information though. Bar3D's speed is fine if you have a fast hline implementation (like for e.g. go32v2 in most modes). It's asm, it should be faster than pascal code. That is not why it is that much faster. That code would be almost equally fast if it were written in Pascal. I wrote it in assembler because I liked doing that, not because it was needed for speed reasons. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
On 22 Aug 2007, at 21:18, Micha Nelissen wrote: Michael Van Canneyt wrote: Why is calling via a procvar very much slower than a normal call ? It's just an extra memory fetch (hopefully in cache) ? Jonas meant that each pixel is drawn separately. The procvar is not the issue. Before me going too far in unknown territory, but isn't that the basis for any software implemented graphics routine: drawing pixels ? Yes, but not with a call and location calculation per pixel (and who knows what else SLD_putpixel does behind the scenes). And in case of horizontal lines, you usually draw several pixels at a time (or at least blit them using a fillchar/word/dword-like routine). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
Michael Van Canneyt wrote: >> Why is calling via a procvar very much slower than a normal call ? It's >> just an extra memory fetch (hopefully in cache) ? > > Jonas meant that each pixel is drawn separately. The procvar is not the issue. Before me going too far in unknown territory, but isn't that the basis for any software implemented graphics routine: drawing pixels ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
On Wed, 22 Aug 2007, Micha Nelissen wrote: > Jonas Maebe wrote: > > No, it is still slow. You indeed do not have locking overhead, but you > > are still calling nonBuf_DirectPutPixel via a procvar for each pixel > > which has to be drawn (from hlinedefault). That is still very slow. > > Why is calling via a procvar very much slower than a normal call ? It's > just an extra memory fetch (hopefully in cache) ? Jonas meant that each pixel is drawn separately. The procvar is not the issue. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>: > > > On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote: > > > 2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>: > >> > >> > >> It is because you do not redirect the line drawing directly to SDL, > >> but instead use the default line drawing routines. Those are indeed > >> very slow, because they call a procedural variable (directputpixel) > >> for each pixel which has to be drawn). And directputpixel then calls > >> through to SDL, which every time must recalculate the pixel position > >> on the screen (instead of just adding 1 to the horizontal or vertical > >> coordinate in case of horizontal/vertical line drawing). > > > > Hm... I really forgot to hook Line (but wrote the routine). But > > HLine and > > VLine are hooked and the speed problem is in the Bar function, it > > has such > > code: > >for y:=y1 to y2 do > > Hline(x1,x2,y); > > HLine is hooked and works quickly. But it locks the screen every > > time it is > > executed (but calls DirectPutPixel without locking (that's why it > > is fast): > > procedure sdlgraph_HLine(x,x2,y: smallint); > > var > > temp:DefPixelProc; > > begin > > temp:=DirectPutPixel; > > DirectPutPixel:[EMAIL PROTECTED]; // It doesn't lock the > > screen as > > sdlgraph_DirectPutPixel. It's quick. > > No, it is still slow. You indeed do not have locking overhead, but > you are still calling nonBuf_DirectPutPixel via a procvar for each > pixel which has to be drawn (from hlinedefault). That is still very > slow. Hm... I've tried such thing: procedure sdlgraph_HLine(x,x2,y: smallint); begin SDL_DrawLine(screen,X,y,x2,y,255); SDL_Flip(screen); end; The same. I will try to find the true way, but I'm not sure that it can be without locking overhead. I reimplement Bar3d with adding locking - very quick. I think it is the fastest HLine implementation Bar3D's speed is fine if you have a fast hline implementation (like > for e.g. go32v2 in most modes). It's asm, it should be faster than pascal code. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
Jonas Maebe wrote: > No, it is still slow. You indeed do not have locking overhead, but you > are still calling nonBuf_DirectPutPixel via a procvar for each pixel > which has to be drawn (from hlinedefault). That is still very slow. Why is calling via a procvar very much slower than a normal call ? It's just an extra memory fetch (hopefully in cache) ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote: 2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>: It is because you do not redirect the line drawing directly to SDL, but instead use the default line drawing routines. Those are indeed very slow, because they call a procedural variable (directputpixel) for each pixel which has to be drawn). And directputpixel then calls through to SDL, which every time must recalculate the pixel position on the screen (instead of just adding 1 to the horizontal or vertical coordinate in case of horizontal/vertical line drawing). Hm... I really forgot to hook Line (but wrote the routine). But HLine and VLine are hooked and the speed problem is in the Bar function, it has such code: for y:=y1 to y2 do Hline(x1,x2,y); HLine is hooked and works quickly. But it locks the screen every time it is executed (but calls DirectPutPixel without locking (that's why it is fast): procedure sdlgraph_HLine(x,x2,y: smallint); var temp:DefPixelProc; begin temp:=DirectPutPixel; DirectPutPixel:[EMAIL PROTECTED]; // It doesn't lock the screen as sdlgraph_DirectPutPixel. It's quick. No, it is still slow. You indeed do not have locking overhead, but you are still calling nonBuf_DirectPutPixel via a procvar for each pixel which has to be drawn (from hlinedefault). That is still very slow. Bar3D's speed is fine if you have a fast hline implementation (like for e.g. go32v2 in most modes). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpmkunit patch 22-aug
On Wed, 22 Aug 2007, Darius Blaszijk wrote: > Here's my last patch for now for fpmkunit. As it seems all commands are fixed > now. I need to add the last bit to the documentation, but it's pretty up to > date as it stands. > > - replace MatchesMask function by IsWild function from StrUtils > - fixed listsources command Excellent, applied the patch, thanks ! Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>: > > > It is because you do not redirect the line drawing directly to SDL, > but instead use the default line drawing routines. Those are indeed > very slow, because they call a procedural variable (directputpixel) > for each pixel which has to be drawn). And directputpixel then calls > through to SDL, which every time must recalculate the pixel position > on the screen (instead of just adding 1 to the horizontal or vertical > coordinate in case of horizontal/vertical line drawing). Hm... I really forgot to hook Line (but wrote the routine). But HLine and VLine are hooked and the speed problem is in the Bar function, it has such code: for y:=y1 to y2 do Hline(x1,x2,y); HLine is hooked and works quickly. But it locks the screen every time it is executed (but calls DirectPutPixel without locking (that's why it is fast): procedure sdlgraph_HLine(x,x2,y: smallint); var temp:DefPixelProc; begin temp:=DirectPutPixel; DirectPutPixel:[EMAIL PROTECTED]; // It doesn't lock the screen as sdlgraph_DirectPutPixel. It's quick. Slock; HLineDefault(x,x2,y); Sulock; DirectPutPixel:=temp; end; If to do the same (using nonBuf_HLine) with Bar3D it would be very fast. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
On 22 Aug 2007, at 12:26, Evgeniy Ivanov wrote: Bar3D is indeed one of the few routines which cannot be hooked currently. As long as you hook the line drawing it should be plenty fast though. No, I tryed. It is in the test.pas. It works very very slow. It is because you do not redirect the line drawing directly to SDL, but instead use the default line drawing routines. Those are indeed very slow, because they call a procedural variable (directputpixel) for each pixel which has to be drawn). And directputpixel then calls through to SDL, which every time must recalculate the pixel position on the screen (instead of just adding 1 to the horizontal or vertical coordinate in case of horizontal/vertical line drawing). I may patch graph.inc, graphh.inc and modes.inc to add ability to hook such routines (Shapes/Lines) like Bar3D. It will not take any effect on currently written modules (Current Bad3d may be Bar3Ddefault and to be added to Bar3D proc if it's not assigned). Of course if you will approve it (I don't see any reason to make it just for my needs). I really don't think it will be needed. This will indeed be difficult. It's probably best to create a generic "wincrt"-like unit (sdlcrt?) which can be used together with the sdl graph unit. Full input/output support can also be added to it over time, similarly to how the regular crt unit also takes over all input/ output. Nice idea. I may do it. I think that the best way for this is to use SDL-terminal (I have never used it, but it must be pretty nice). But it isn't in JEDI-SDL (so, it must be wrapped to .pp). But I prefer to use readln to give user a chance to see the screen created by graph (and close after any key was pressed). There are many old programmes with it. The "+" of SDLgraph is that it may be used with old code and you may add any JEDI-SDL routine (timer or SDL_mixer and so on) using global screen variable. Sorry for my poor English, but I think you will get the idea. Yes, sounds good. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>: > > > Congratulations! Just one note: please do not make it GPL, because > that would mean anyone using that unit would have to make their > program also GPL. Instead, please change the text at the top to > something like this: > > *** > Copyright (c) 2007 Evgeniy Ivanov > > This file implements the sdl support for the graph unit > > See the file COPYING.FPC, included in this distribution, > for details about the copyright. > > This program is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > *** > > You're of course free to also include your email address and a link > to your website, like you have done in the version you put on the web. Ok, no problem. I will do it in the way you have told. I'm waiting when they will register the project (there is sdlgraph on sf.net, but it's old and empty, they need to check it). > I need to do some hooks to speed up the module (Bar3d). But I have > > network > > problems and my dial up doesn't me allow to google much (I don't > > know how to > > hook functions/procedures). > > Bar3D is indeed one of the few routines which cannot be hooked > currently. As long as you hook the line drawing it should be plenty > fast though. No, I tryed. It is in the test.pas. It works very very slow. I may patch graph.inc, graphh.inc and modes.inc to add ability to hook such routines (Shapes/Lines) like Bar3D. It will not take any effect on currently written modules (Current Bad3d may be Bar3Ddefault and to be added to Bar3D proc if it's not assigned). Of course if you will approve it (I don't see any reason to make it just for my needs). > Also readln function need to be hooked too (It works when alt+tab > > to console > > from which app was executed). > > This will indeed be difficult. It's probably best to create a generic > "wincrt"-like unit (sdlcrt?) which can be used together with the sdl > graph unit. Full input/output support can also be added to it over > time, similarly to how the regular crt unit also takes over all input/ > output. Nice idea. I may do it. I think that the best way for this is to use SDL-terminal (I have never used it, but it must be pretty nice). But it isn't in JEDI-SDL (so, it must be wrapped to .pp). But I prefer to use readln to give user a chance to see the screen created by graph (and close after any key was pressed). There are many old programmes with it. The "+" of SDLgraph is that it may be used with old code and you may add any JEDI-SDL routine (timer or SDL_mixer and so on) using global screen variable. Sorry for my poor English, but I think you will get the idea. > If you remember we were talking about it in April (or May). I've > > created > > sf.net project, but it is in Processing Queue. So, here are the > > temp links: > > > > Unit: http://itmo.vingrad.ru/files/sdlgraph.pas.txt > > > > Example: http://itmo.vingrad.ru/files/test.pas.txt > > > > Build script (you need to fix paths): > > http://itmo.vingrad.ru/files/build.sh.txt > > Very nice! Thanks a lot! :) > P.S. Thanks you for your answers about the graph modules and to > > authers of > > graph*.inc and *Go32* module - the code is very nice. > > Carl will be happy to hear this :) > > > > No, it doesn't do the same: the lowNewMode..highNewMode case uses > IntcurrentNewDriver, while the else case uses IntcurrentDriver. It's > to transparently support both the old and new mode selection logic. > > > TODO: in modes.inc 181: Overloaded procedure initmode(var mode: > > TModeInfo); > > isn't used. I've looked only in modes.inc, so it may be my mistake > > It is used by all platform-specific graph units (also by your > sdlgraph unit) to initialise a new mode. Thanks, sorry my inattention. > TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode = > > Init640x480x32k > > } > > Fixed, thanks. You're welcome :) -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
