Page 1 of 1

About window -> Smooth scrolling

Posted: Mon May 19, 2008 8:14 pm
by eriansa
I wonder what is the best approach to create an about window with smoothly scrolling text over a background image. (OpenGL/DirectX?)

tia.

Posted: Mon May 19, 2008 8:29 pm
by Kaeru Gaman

Posted: Tue May 20, 2008 1:39 am
by netmaestro
You can try this one, doesn't use DX, just API:

(most of the code is strings)

Code: Select all

; yet another useless program by netmaestro 

Global hBrush 
Global Dim string.s(100) 

string(0) = "Hi, " 
string(1) = "Update: 4.20 Beta 6 for Windows is out, 4.20 Beta 2 for Linux and 4.20 Beta 1 for MacOS X as well ! " 
string(2) = "Here is the fifth beta release of the forthcoming 4.20 version of PureBasic. It's getting longer as expected, and we would like to spend some time to explain why." 
string(3) = "Don't flip out, it will be probably the last beta, If everything goes nicely. Here is the story: " 
string(4) = "" 
string(5) = "At first, 4.20 was meant to be a 'new command only' release. So no big problems were foreseen, as we won't work on the compiler Or debugger. Better, most of the" 
string(6) = "new libraries were already written, as we often do extra interresting work when fixing bugs is becoming too boring (we don't include the new library in the release" 
string(7) = "tree, so the library can maturate pacefully). So good so far, 2 months after the 4.10 release, a new beta hit the ground. and now, things got a bit more complex. " 
string(8) = "We encounter again a LccWin32 bugs/limitation so we decided it was time to migrate to VisualC++ 2005. This choice was made for serveral reasons:" 
string(9) = "" 
string(10) = "      1) It is the 'official' C/C++ compiler on Windows " 
string(11) = "      2) It is free (we use the excellent 'Express' edition) " 
string(12) = "      3) It produce very good code (much better than lcc - some libs gained 50-100% in speed just by switching the compiler)" 
string(13) = "      4) It has a X64 version as well, so we have a direct port to 64 bits Windows without too much hassle (at least for the libraries) " 
string(14) = "      5) Bug free (at least on the compiler side) " 
string(15) = "" 
string(16) = "So we started so migration of all the libraries and compiler libraries (SystemBase, StringManager, etc..). Some of them used lcc inline ASM, so needed quite some" 
string(17) = "work to have them to work. VC++ is also more picky and tons of warning appears and needed a correction. Moreover we activated the 64 bits portability check and" 
string(18) = "our console were definitely flooded. Think than when we migrate the whole commandset, it affect tousand of files, all the makefiles needs to be adapted etc. But" 
string(19) = "as you can understand, it is for the best. Several weeks later, we got everything building fine and as you guessed it, the 64 bits compiling was (almost) working" 
string(20) = "as well. It was the base to begin the work for the famous X64 compiler. " 
string(21) = "" 
string(22) = "We though we were done with this, but a strange VC8 optimisation affected the way PureBasic called string functions (PureBasic assumed than the arguments passed" 
string(23) = "on the stack for the functions would never be modified by a C function (and it is the Case with lcc and gcc). But there is no clear infos on this, and VC8 " 
string(24) = "actually use the stack parameters as temp area If needed). So a compiler modification was needed to fix that, after a lot of investiigation (we got random crashes" 
string(25) = "on some functions). In between, we faced some regressions so we have written much more unitary tests to make the commandset more robust to changes. These are" 
string(26) = "running using the 'PureUnit' tool developped by Timo (Fr34k) which will made its way in the official PB package soon, as it's really a great help to ensure a " 
string(27) = "module behaves as expected, on every plateform. " 
string(28) = "Now that all the libraries and helpers were compiled with VC8, we couldn't let the compiler itself using Lcc. So we started the migration as well. The gains for the" 
string(29) = "compile time was good (10-30%) but we needed to trick a bit VC8 to use an old VC runtime dll (MSVCRT.dll) instead of the new VC8 one, as it wouldn't run out of the" 
string(30) = "box without shipping the VC8 runtimes. Google helped here . " 
string(31) = "" 
string(32) = "On another topic, CVS is dying and replaced everywhere by SVN. We migrated the libs repository some time ago, but the compiler and internal tools were still using" 
string(33) = "this old aged CVS. The migration wasn't very smooth as the CVS repository was on an NT based computer While the script needed to do the migration were on linux." 
string(34) = "After some twists, it finally worked. So SVN everywhere. And it's way better, honestly. " 
string(35) = "" 
string(36) = "Timo wanted to add a profiler to the IDE, so he did. And he did well. So it remainded me than i didn't profiled the compiler since a while and it could be quite " 
string(37) = "fun to do. I tried to find a good profiler on Windows (anyone ?) but only found the costly Quantify (and even, the demo version showed only API call with VC8 " 
string(38) = "executable, dunno If it's on purpose Or If it's a bug). So i fired it my linux box and used gprof and the linux compiler. I used the IDE source code as benchmark" 
String(39) = "(60 000 lines). And here, the disaster: 23 millions of stricmp() call - called when looking for a token (like constant, Structure, Procedure, functions, Macro etc.)" 
string(40) = "Seems like my old lookup tables are suffering here. For sure, the residents have almost 8000 constants and the lookup table was way too small. I decided to change " 
string(41) = "that with real hash map. The gain was impressive, now only 500 000 calls to stricmp() are done. The whole processing time of the source code fall down from 3500 ms" 
string(42) = "to 500 ms on my computer. This optimisation is available in the Beta 5, so If you have a big project, you may feel the difference. " 
string(43) = "" 
string(44) = "We also wanted to tackle most of the important remaining bugs since the last 4.10 version (and even before), so we spend quite some time to fix thus (on the 3 OSes)." 
string(45) = "This led me to rework the 'QuadUnit', which is used to manipulate and execute quad based operation. The one developped for PB 4.00 was good but way too complex" 
string(46) = "and some case were really hard to handle. So i simplified the whole design and recoded several key part. This change is also in Beta 5, so don't hesitate to report" 
string(47) = "bugs If any. At least, all the quad reported bugs are now fixed. It should have no Or very few regression as all fixed bugs are part of the compiler unit tests" 
String(48) = "(every compiler bugs fixed get a new entry in the regression test suite). " 
string(49) = "" 
string(50) = "In fact, we added too much commands for a single version, but hey, we are megalomaniacs. Thus we got plently bugs reports on these (logically as these new" 
string(51) = "libraries were not trivials). Thanks to all of you for the reports and the patience. " 
string(52) = "" 
string(53) = "As we can't stop, when we need to work on some fresh stuffs, we started the 64 bits version of PureBasic and the MacOS X x86 version. One could think than the" 
string(54) = "MacOS X x86 version would be just a matter a recompiling, but you couldn't be that wrong. OS X x86 ABI is just horrible and need very strick stack alignement" 
string(55) = "everywhere (on 16 bytes boundaries) which the Windows/Linux version doesn't requiers. If the stack is misaligned, it sometimes work, sometimes not, leading to very" 
string(56) = "hard to track bugs. So, the compiler has been reworked to handle stack alignment all over the code. Moreover, FASM is not available on OS X x86, so we decided to" 
string(57) = "migrate all the assembly libraries (linked list, misc etc.) on NASM. Indeed the compiler has been modified to output NASM compatible code instead of FASM." 
string(58) = "On the x64 side, the work has been even harder as the assembly itself isn't the same. Well, both are coming quite nicely, and the public test will come soon. " 
string(59) = "" 
string(60) = "The last but not the least, many new commands means a lot of doc to write. This takes a lot of time, as we do it in 3 languages as you know. The beta 5 comes with" 
string(61) = "the doc in 3 langages, for all new commands. " 
string(62) = "" 
string(63) = "Ok, so you can grab the beta 5 on your account and test it. The beta for Linux and OS X are ready as well, but we will wait a bit before publishing them" 
String(64) = "(to see If there is no major quirks. And btw, If you were using the beta 4, check your 'Temp' directory as a nasty bug didn't remove all the PB temp dirs and it" 
string(65) = "could take some space. " 
string(66) = "" 
string(67) = "Have fun ! " 
string(69) = "" 
string(70) = "The Fantaisie Software Team" 
string(71) = "" 
string(72) = "" 
  
Procedure Draw(uID,uMsg,dwUser,dw1,dw2) 
  Static y=600 
  y-1 
  If IsImage(1)
    hdc=StartDrawing(ImageOutput(1)) 
      SelectObject_(hdc, hBrush) 
      Rectangle_(hdc,0,0,800,600) 
      DrawingMode(#PB_2DDrawing_Transparent) 
      DrawingFont(GetStockObject_(#DEFAULT_GUI_FONT)) 
      For i=0 To 72 
        If y+i*16<600 And y+i*16 >-16 
          DrawText(10,y+i*16,string(i),#White) 
        EndIf 
      Next 
      If y+72*16 < -16 
        y=600 
      EndIf 
    StopDrawing() 
  EndIf
  If IsImage(1) And IsGadget(0)
    SetGadgetState(0,ImageID(1)) 
  EndIf
   
EndProcedure 

OpenWindow(0,0,0,800,600,"PureBasic 4.20 Beta News",#PB_Window_SystemMenu|#PB_Window_ScreenCentered) 

LoadImage(0, "c:\windows\prairie wind.bmp") ; or an image of your choice 
hBrush = CreatePatternBrush_(ImageID(0)) 

CreateImage(1, 800,600, #PB_Image_DisplayFormat) 
hdc = StartDrawing(ImageOutput(1)) 
  SelectObject_(hdc, hBrush) 
  Rectangle_(hdc,0,0,799,599) 
StopDrawing() 
CreateGadgetList(WindowID(0)) 
ImageGadget(0,0,0,800,600, ImageID(1)) 

TEvent = timeSetEvent_(40,0,@Draw(),0,#TIME_PERIODIC) 

Repeat : Until WaitWindowEvent()=#PB_Event_CloseWindow 

timeKillEvent_(TEvent) 
DeleteObject_(hBrush) 
Delay(15)
End 

Posted: Tue May 20, 2008 2:31 am
by rsts
Another nice one by the network maestro :D

(no windows\prairie wind.bmp for us vista users though).

Many thanks for the lesson.

cheers

Posted: Tue May 20, 2008 3:45 am
by netmaestro
Thanks for the kind words, rsts. Code is now updated to keep the animation going while the window is being moved around by the user (just seems more professional that way)

Niiiice

Posted: Tue May 20, 2008 5:53 am
by Fangbeast
That's beautiful netmaestro. I put a picture of a seashore with a large conch shell in the background.

Very nice code and effect.

Posted: Tue May 20, 2008 9:45 am
by srod
; yet another useless program by netmaestro
:lol:

That always cracks me up.

Posted: Wed May 21, 2008 1:49 pm
by eriansa
Thanks! :D

Posted: Wed May 21, 2008 5:05 pm
by Sparkie
Very nice netmaestro :)

One thing you may need to add...
msdn - timeSetEvent wrote:Remarks-
Each call to timeSetEvent for periodic timer events requires a corresponding call to the timeKillEvent function.

Posted: Wed May 21, 2008 6:34 pm
by netmaestro
Yes, thanks for pointing it out I often forget that one. I've always liked TimeSetEvent because it's a one-line solution to true 1-millisecond timer resolution, much less messy and more accurate than timeGetDevCaps - timeBeginPeriod etc. But I have to keep telling myself - it's two lines, idiot, two lines!

Posted: Mon May 26, 2008 4:48 pm
by Rescator
Here is a nice example I threw together, inspired by the code above.
With some tweaks it could probably do well as a end game credits scroller etc.
http://www.purebasic.fr/english/viewtopic.php?p=245435

Posted: Tue May 27, 2008 1:45 pm
by Fangbeast
netmaestro wrote:Thanks for the kind words, rsts. Code is now updated to keep the animation going while the window is being moved around by the user (just seems more professional that way)
Stupid question coming up here. (I've seen rescators's version changing colours every so often. it was nice, but your routine is much smoother on my system).

Wouldn't it be easier to have all the text in DataSections and have your code read through to the end instead of having an arbitrary end number?

And have an optional parameter each line for colour and font and font size?

Please pardon me being way out in left field as usual.

P.s. It's nice to see the 3 wizards in the same thread. I can feel the magic flow (No srod, it is not political bulldust I am referring too, settle down!!)

Posted: Tue May 27, 2008 6:12 pm
by Sparkie
Fangles wrote:Wouldn't it be easier to have all the text in DataSections and have your code read through to the end instead of having an arbitrary end number?
I use a different approach to my scrolling text which enables me to put all my text into an HTML file and then add it as a resource. For ME, I find it easier to edit the scrolling text this way and it helps reduce MY code clutter. 8)

Posted: Tue May 27, 2008 10:00 pm
by Rescator
Fangbeast wrote:Stupid question coming up here. (I've seen rescators's version changing colours every so often. it was nice, but your routine is much smoother on my system).
Reason mine is slower is because it's very multitasking friendly, if the system is somewhat busy then the scroll thread will pause for a short while.
You can speed/smooth things more by getting rid of some delays in it.

And I replied in the other thread with some ideas on what can be done to speed things up more.

If it wasn't for the fact that netmaestro's cool scroll lacked size support and wrapping and text colors I prolly wouldn't have made that one.

So netmaestro, any improvements planned on your code?
It wouldn't hurt to have another implementation in the tricks and tips section, more cool code for people to find when searching the forums ;)

Edit:
One thing I can think of is drawing the text twice, the first time 1 pixel slightly off with black for example, and then the text on top of that as normal. Should give a nice "shadow" effect that would look very nice on top of a background image.