240*320 Resolution

[jbmaster]

Wiz is used in 240 * 320 resolution OLED(Recommended) will support.

Difficult to port the content(320*240) is developed?

 

[Pickle]

Wiz is used in 240 * 320 resolution OLED(Recommended) will support.

Difficult to port the content(320*240) is developed?

I think the main concern going this route it that there is a loss of performance to do the rotation.

 

[Exophase]

Wiz is used in 240 * 320 resolution OLED(Recommended) will support.

Difficult to port the content(320*240) is developed?

I think the main concern going this route it that there is a loss of performance to do the rotation.


Where possible you should combine the rotation into whatever code is doing the final write out to the framebuffer. You can do this by incrementing by 240 pixels between writes instead of by 2. This does remove any opportunity to write more than 2 bytes sequentially (using str or stm) which affects write buffer performance, but Wiz is somehow able to write out non-sequential bytes off the write buffer quickly, maybe as quickly as merged ones.

Writing into a temporary 320x240 buffer then rotating that to 240x320 once per frame is going to take a much bigger hit because of all the cache it'll be blowing through.

 

[notaz]

Wiz is used in 240 * 320 resolution OLED(Recommended) will support.

Difficult to port the content(320*240) is developed?

Can't you just fix the hardware? Is that impossible?

 

[Exophase]

The diagonal tearing isn't that bad anyway.

As far as I'm aware, 240x320 mode doesn't work in the current firmware either :/ Could be something wrong with the ioctl Orkie does though.

 

[Squidge]

As far as I'm aware, 240x320 mode doesn't work in the current firmware either :/ Could be something wrong with the ioctl Orkie does though.

It's the kernel apparently. I asked Orkie and got "You don't have the correct firmware! It will not work in your version, only test version ".

 

[Flavor]

Is this the whole GP32 thing over again or am I missing the point?

Jeff F. had a nice ASM routine that was used often for doing a final screen rotation. "xlatgp32.s"

 

[Exophase]

Is this the whole GP32 thing over again or am I missing the point?

Jeff F. had a nice ASM routine that was used often for doing a final screen rotation. "xlatgp32.s"

There's a real 320x240 mode, it just has a bug that 240x320 mode doesn't.

Like I said in my previous post, doing a separate rotation on the whole framebuffer is never the most efficient answer, no matter how well written that rotation is. This should only be done if the speed can be spared (but even then, something faster would mean better battery utilization).

 

[Squidge]

I've got the kernel source, the latest kernel, and example code for the LCD module. I'm currently investigating whether or not something can be done in software.

So far, I've released a version of my Vectrex emu for the Wiz which supports dynamic selection of 320x240 and 240x320 using the shoulder buttons. I don't notice any odd effects on the LCD in either mode, but maybe thats because it's mostly wireframe.

 

[Pickle]

I've got the kernel source, the latest kernel, and example code for the LCD module. I'm currently investigating whether or not something can be done in software.

So far, I've released a version of my Vectrex emu for the Wiz which supports dynamic selection of 320x240 and 240x320 using the shoulder buttons. I don't notice any odd effects on the LCD in either mode, but maybe thats because it's mostly wireframe.

You need something with a lot of motion, the worst case ive found is vice. For example some c64 apps when loading would cycle lines of different colors all over the screen. The diag tear is very obvious. I actually recorded this situation in my c64 video in the archives.

Edit: FCE was also released with both video modes

 

[Flavor]

There's a real 320x240 mode, it just has a bug that 240x320 mode doesn't.

Ahh, yes, so I was missing something. Good.

Like I said in my previous post, doing a separate rotation on the whole framebuffer is never the most efficient answer, no matter how well written that rotation is. This should only be done if the speed can be spared (but even then, something faster would mean better battery utilization).

Yes, of course. Though, when porting code, coders will rarely want to rework the internals to use 240x320 mode. In my GP32 days, if I wrote an app for GP32, I tried to do it in 240x320, but when I was porting, then I would use the xlatgp32 code. Anyway, it is good to know that there are options.

 

[quasist]

How OpengGL ESing will be affected by it? Demos looks stable

 

[jbmaster]

Optimized for conversion is looking for library.

check please..

CODE
http://hanmaro.netorage.com:8712/cgi-bin/fileindex.cgi?cmd=read&uid=jbmaster&indexid=4B2613FE23A9C604&fpw=41035507.jpg

 

[Exophase]

No, fix it ;p

 

[senquack]

Fix it, GPH, don't be lazy again.

You know how long it would take me to write a "conversion library" (actually a short function with a loop and some LDM/STMs in assembly)? Jeez, about two hours maximum probably less than an hour.. We don't need a library, we need fixed hardware.

You always promised stick-click emulation for the F200 but never delivered. Know how long it took me to add into the Open2X kernel? One night. And I am a complete amateur.

 

[jbmaster]

Fix it, GPH, don't be lazy again.

You know how long it would take me to write a "conversion library" (actually a short function with a loop and some LDM/STMs in assembly)? Jeez, about two hours maximum probably less than an hour.. We don't need a library, we need fixed hardware.

You always promised stick-click emulation for the F200 but never delivered. Know how long it took me to add into the Open2X kernel? One night. And I am a complete amateur.

" You always promised stick-click emulation for the F200 but never delivered. "
Sorry. You do not know any details about the above-mentioned.
Maybe I'm looking at what was there before working in GPH.

 

[Flavor]

Fix it, GPH, don't be lazy again.

You know how long it would take me to write a "conversion library" (actually a short function with a loop and some LDM/STMs in assembly)? Jeez, about two hours maximum probably less than an hour.. We don't need a library, we need fixed hardware.

You always promised stick-click emulation for the F200 but never delivered. Know how long it took me to add into the Open2X kernel? One night. And I am a complete amateur.

" You always promised stick-click emulation for the F200 but never delivered. "
Sorry. You do not know any details about the above-mentioned.
Maybe I'm looking at what was there before working in GPH.


I thought that I already posted the "library".
http://www.devrs.com/gp32/files/xlatgp32.s

Though, I think the consensus is that you should not use such a hack. Just fix the problem. Now, of course, this "library" will be in the final product. You'd better pay Jeff F. royalties.

 

[Exophase]

I thought that I already posted the "library".
http://www.devrs.com/gp32/files/xlatgp32.s

Though, I think the consensus is that you should not use such a hack. Just fix the problem. Now, of course, this "library" will be in the final product. You'd better pay Jeff F. royalties.



Close, you mentioned it by filename, no link though.

Unfortunately this routine only works on 8bit framebuffers, so it won't be universally useful. It's also not quite optimal, although with the write buffer characteristics I found on Wiz I doubt you could improve it very much (there is a one cycle stall in there)... still, if you merge it up to do 4x4 blocks and 32bit writes it'll possibly be faster.

I'm curious now, I'll probably do some benching later. Then if it's better, withhold the source from GPH for a while so they try to fix the problem :/

 

[Alex.]

Please provide a way to use the fast 320x240 mode from the firmware's SDL, the screen diagonal problems are virtually unnoticeable in most games, and fast performance is much more important.

By the way, does OpenGL|ES render to 240*320 natively, or does it need the screen rotation as well?

 

[Exophase]

Please provide a way to use the fast 320x240 mode from the firmware's SDL, the screen diagonal problems are virtually unnoticeable in most games, and fast performance is much more important.

By the way, does OpenGL|ES render to 240*320 natively, or does it need the screen rotation as well?

Are you sure you're going to want to use the SDL on the firmware? >_>