Compilepalooza!

Okay, I found some time this morning to think about this properly for 10 minutes.

#define SIMPLE_565          { 240, 320,   2, 480, 16, kfDirect | kfDirect565, TRUE }

240 pixels wide @ 16-bits per-pixel (2 byte) and it says that the pitch stride is 2-bytes.

... taking a tabulation view says that 2 bytes from the start of the ROW (16-bit) is one pixel to the right, thus pixel 2.

 Pixel: 

Row 1: 0, 1, 2, 3, 4... 239 

Row 2: 240, 241, 242, 243, 244... 

So if that is correct, we can validate it using cbyPixel: 480 bytes after pixel 1 at 16-bit (2-bytes) per-pixel = 240 pixels after the first pixel of the first row which is pixel 241 which is the start of row 2 as represented in linear memory. Add another 480 bytes (240 pixels) to that and you are at the start of row 3 and so on.


So if we reverse engineer that logic for 720x576 and we assume that there isn't a cache at the end of the stride row, the correct values to compensate for the pitch stride should be:

#define SIMPLE_565          { 720, 576,   2, 1440, 16, kfDirect | kfDirect565, TRUE }

So logic would dictate that to automate it:

 

// Get the device context of the screen  

HDC hScreenDC = CreateDC(_T("DISPLAY"), NULL, NULL, NULL);       

  

int cxWidth = GetDeviceCaps(hScreenDC, HORZRES);     // cxWidth or GetSystemMetrics(SM_CXFULLSCREEN);  

int cyHight = GetDeviceCaps(hScreenDC, VERTRES);      // cxHeight or GetSystemMetrics(SM_CYFULLSCREEN);  

// cbxPitch [number of bytes to move right one x pixel, can be negative]  

// cbyPitch [number of bytes to move down one y pixel, can be negative]  

int cBPP = GetDeviceCaps(hScreenDC, BITSPIXEL);        // bpp  

int ffFormat = (kfDirect | kfDirect565);                          // format  

BOOL bBuffer = TRUE                                                    // bDRAMBuffer  

  

DeleteDC(hScreenDC);  

  

// Configuration, select what you want from above list  

Config      l_config         = { cxWidth, cyHeight, 2,  (cxWidth * 2), cBPP, ffFormat, bBuffer };  

Both of them give me a fatal application error
What c:amie suggested after having done the math seems very promising, I'd say we should try

#define SIMPLE_565          { 720, 576,   2, 1440, 16, kfDirect | kfDirect565, TRUE }

next

ok here

Oh my gosh.. we're a massive step further
Using the "double pixel" setting in the MilkyTracker config it's a little cut off and with the default settings it's a bit small, but it's technically already 100% usable!

I guess it might be caused by MilkyTracker not actually running at a resolution that's compatible with the PAL resolution we set, though for some reason the MilkyTracker window doesn't fill all of the screen, even though it should be doing that

@c:amie, you're fantastic! Amazing job figuring out the math of those pixel pitch variables!







Attachments
----------------
a little too big.jpg (88KB - 0 downloads)
a little too small.jpg (77KB - 0 downloads)

Well do you think we should try 640x480 next because theoretically it should fit within your window ?

As it is drawing into a canvas, it looks as though the consideration should be over the window frame size perhaps rather than the screen size as it is disappearing beneath the taskbar (which would be 720x550).

#define SIMPLE_565          { 720, 550,   2, 1440, 16, kfDirect | kfDirect565, TRUE }

I am surprised though that it hasn't filled the full screen. I wonder if that is because computationally the Pocket PC is drawing yx instead of xy.

So try flipping the draw order around too:

#define SIMPLE_565          { 550, 720,   2, 1440, 16, kfDirect | kfDirect565, TRUE }

C:Amie, in future do you want me to upload two versions of the dll?
One compiled for HPC2000 x86 and the other for PocketPC 2002 x86?
That way we can eliminate bugs easier that way?

Neither are of any use to me torch, so do what you need to do. Please delete old ones though, no sense leaving the forums cluttered with flack.

p.s. why do we need builds for PPC at all?

Ha!
I’ll upload x86 HPC2000 only.

And I don’t know why..I was randomly button clicking sorry!
Yes I’ll delete those now.

Anyway let me me know IDFB (I dunk for bananas) if you want me to double compile for Hpc2000 and 4.2 x86

Honestly I'm not sure, whatever you did the last time ran fine
Once we have the resolution thing sorted out we can compile for as many targets as possible. You should also try running Milky Tracker on your x86 CE device too!

Edited by I dunk for bananas 2022-12-10 3:34 PM

Unless we implement some dynamic resolution awareness, there's little point building 1000 versions as they're just device specific.

There is a reason why Frank at WinCeSoft has included that vast lookup table, it's because these configs matter.

That is true!

@torch, could we try compiling it with:

#define SIMPLE_565          { 550, 720,   2, 1440, 16, kfDirect | kfDirect565, TRUE }

like c:amie suggested?

What if I put this on my GitHub as an experiment ? (I don’t want to put on hpcfactor until I get more practice )
That way it doesn’t clog up the SCL. I don’t mind compiling a million versions if people have use for them.

Also sorry I’ll compile tonight. I’m at work now

Edited by torch 2022-12-10 4:20 PM

I think we should get something that works before worrying about how to redistribute it.

Sorry yes I know. I mean for the future when it is working