Week Summary: GFX and File System tests [Week 3-4]

Hi everyone,

Last week I was working on GFX subsytem tests. Currently we have following tests in working condition with some details about each of them:

  1. Blitting Bitmap on screen: This is the most basic GFX test, here we display a colored rectangle on the screen using game palettes. If this works, most GFX drawing will.
  2. GFX Transactions:
    • Full Screen Mode : Here we toggle between the fullscreen and windowed states, ask user which state is it and based upon the response the engine decide if it works or not.
    • Aspect Ratio: As described in the last post
    • Iconfiying Window: As described in the last test
  3. Cursor Tests:
    • Palettized Cursors: Use game palette and cursor palette to render the cursor on screen.
    • Scaled Cursors: For testing scaled cursors, what I do now is set different graphic mode scale factors and vary the cursorTargetScale parameter, the cursor should behave accordingly. (However, this currently needs some rework)
  4. Effects
    • Shaking feature : displays a word on screen and makes it shake.
    • Setting and hiding focus: I tried with two rectangles on the corner and toggle focus between the two. However, this optional feature might not be implemented on every backend, or in other words they simply do nothing.
  5. Overlay Graphics
    Here, we use overlay graphics to display some graphics on screen. However, this test needs some fix as in currently I am not able to notice any change despite of my few attempts. :(.
  6. Palette Rotation
    Palette graphics has one side effect, use can change the display of screen by just changing the palette and without have to draw any pixel. In this test, what I want to do is take some colors, draw some rectangles on the screen, Now rotate the colors in the palette and call updateScreen(), a rotation in colors of the rectangle should be noticed. This test has not been implemented yet, but i am thinking of merging it with the blitting bitmap test where we display rectangle and palettes. Any suggestions are most welcome.
  7. Testing pixel formats.
    We were working with 8bpp (8 bits per pixel) format so far, clearly the 16 + bit pixel  formats should support more colors, the intent here should be to display some “nice gradients”, as Eugene pointed about in his email to me. I assume displaying some colored graphics is what he meant ;-), once again some suggestions about testing it are most welcome.

So that completes the GFX test description, but the work is not complete yet. Some more work is needed with scaled cursors, overlay graphics. Testing features in points 6 and 7 are yet to be implemented as well.

As i was a little bit stuck with the overlay stuff not working and all, I tried my hands on File System tests, just for a change ;-). I hope I would finish up the graphics thing once i return back to them this weekend.

Meanwhile, In the FS tests, I have done/working on the following:

FS tests in addition require some additional infrastructure. Now you would need game-data for the “TestBed” game engine.
Unlike other games TestBed game data is not that fancy ;-), its just a collection of 3 files: two directories and one file. the hierarchy is something like:

testbed –> TESTBED (text file, used for game detection)
|———> testbed  (directory 1)
|                       |—–> testbed.conf
|———> TeStBeD (directory 2)
|—–> testbed.conf

The testbed/ and TeStBeD/ directories contain the same file “testbed.conf” with different data written on them.  We use this case difference to open the appropriate file.

  1. Test Reading File :
    Here, we use the API defined in common/fs.h to access the game root node and open the file “TeStBeD/testbed.conf”, read the information in it and compare it with what it expects. If it founds them same, it marks the test as correct.
    However, this test is not flexible as in if someone tampers with the file “testbed.conf”, the test would fail.
    Any workaround suggestion around this would be much appreciated :).
  2. Test Writing File
    Here I try opening a file using the FS API, in the game root directory, call that “testbed.out”, write some information on it, open that file again for reading, compare the data read to the data written, if they are same, the test works good. In case of any error, the test would fail. So one would need to make sure if the directory is writable or not , unless the test would display wrong results. Any suggestion on this would be much appreciated as well :).
  3. Test Saving game states
    Here what I am trying to do, is preserve the state of testbed engine, if this test is executed write that state to file and when the test is restarted, it should resume from the state it was left to.
    To keep things simple, I am thinking of something like this, We use an array to store which testcase of a testuite are executed and which are running, what i would do is, store the data from the array “_testsToExecute” for a dummy testsuite in the savefile and restart that dummy testsuite, the engine should be able to regenerate the data structure “_testsToExecute” from the savefile state.
    Any suggestions on these will be, as well much appreciated :).

So, thats all for this post. I have asked some questions here as well, assuming that the intended viewers would mostly be  the ScummVM team ;).

Cheers,
—
Neeraj