Improving screen response

Mog
Posts: 28
Joined: Tue Dec 04, 2018 4:01 am
languages_spoken: english
ODROIDs: ODroid Go
Location: North Yorkshire, United Kingdom
Contact:

Re: Improving screen response

Unread post by Mog » Sun Dec 16, 2018 4:04 am

Yeah, that problem bit me on the arse when I wanted to add subpixel rendering to my (not yet finished) console code

I'm in the process of porting RunCPM to it so we can run 40 year old software like Wordstar with the keyboard, it works over the serial atm, and 40/53 columns looks okay but 80 requires a 4x8 font which would have been more readable with subpixel rendering, however due to it being a portrait screen the subpixels are rotated 90 degrees from what I need, heh.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Mon Dec 17, 2018 5:11 am

Cwiiis wrote:Doh, I forgot that the screen is actually 240x320 portrait and not 320x240 landscape - so vertical scrolling is actually horizontal scrolling. That's a huge shame - though it'd be interesting to implement the same optimisation I was thinking of for horizontal scrolling, it's a lot less necessary... I think vertical interlacing is probably out, in that it'd be a huge pain to get the emulator side to cooperate given all the consoles are scanline-based and deal with a landscape orientation. Certainly it'd be much less efficient...

I'll come back to this, I think I'd rather get the other emulators up to speed first (well, at least the SMS/GG emulator). As an aside, I've fixed the aspect ratio in stretched mode now.
Thank you so much for the aspect ratio fix. This is my new goto main firmware now.

Updated test firmware.
Attachments
Test_Nes_ 20181216.zip
Unofficial build
(1005.95 KiB) Downloaded 33 times

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 12:47 am

Been porting over my work to the SMS/GG/Colecovision emulator, but it's been a bit disappointing so far. Possibly there isn't enough code in IRAM and I'm going to start testing with that - if I take away all the display code and buffer diffing code, the emulator can run full-speed in a tight loop with audio, but as soon as you add even just the buffer-diffing, it starts missing its target.

I got some pretty decent improvements on the NES emulator by marking certain functions to go into IRAM, so fingers crossed... I'd have expected the SMS to be a much easier system to emulate fast, but I suppose it is clocked significantly higher... Hopefully these are all just bandwidth issues that can be worked around by shuffling things around in memory.

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 1:28 am

More poking around, I don't think any IRAM shuffling is going to help, but the main speed hit seems to come from the indirection I need to do due to the way the emulator can update the palette on each frame. I can probably cut down on that at the cost of possibly doing more updating than necessary, but at the moment, the diff just isn't fast enough (the NES doesn't have this problem as the palette is fixed).

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 2:32 am

Fixed the issue by being cleverer about when extra work needed to be done and optimising a couple of loops. Still a little concerned that it isn't fast enough - I seem to be seeing a drop in NES performance, but the head of my last branch performs worse than the commit with the SMS work, so either I broke that earlier or there's some other thing on the system that can semi-randomly affect performance? Needs further investigation.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Wed Dec 19, 2018 3:31 am

Cwiiis wrote:Fixed the issue by being cleverer about when extra work needed to be done and optimising a couple of loops. Still a little concerned that it isn't fast enough - I seem to be seeing a drop in NES performance, but the head of my last branch performs worse than the commit with the SMS work, so either I broke that earlier or there's some other thing on the system that can semi-randomly affect performance? Needs further investigation.
So, to get the best overall, I should use the nes.bin from the previous version, the sms.bin of this version and the official gboy.bin?

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 5:26 am

Looks like I caused a performance regression with the aspect-ratio fix commit, I'm just looking at it now - I think the best thing would be to wait a little bit really :) I think my version of sms.bin is worse than the original as it is right now. NES is still better, but not as good as it was before I fixed the stretching.

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 5:33 am

Ah, it's actually pretty obvious what the regression is, but now it means I need to figure out some equations I was putting off :) Not tough, just really fiddily... I was getting them wrong a lot so I just wrote a loop that calculates them in a naive fashion, but it's obviously too slow given how frequently it runs.

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 7:25 am

I've fixed the performance regression, NES is definitely best in the latest commit now. Still uncertain of SMS and there's still progress to be made - SMS has made me realise how tight the CPU margin can be as well as just bandwidth - I think it can get closer to 60fps in interlaced scaled than it is now. As a side note, forcing interlacing on on unscaled NES now pretty rarely drops frames, it's almost a solid 60Hz :)

It'd be nice to write a menu replacement so that I could play around a bit with adding more settings, but really not sure I have the time for that...

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Wed Dec 19, 2018 8:38 am

Thank you! This is going great!

Test firmware updated. Nes and SMS emu come from Cwiis, GNUboy from the official firmware.
Attachments
Test_NES_SMS_20181218.zip
Unofficial build
(1009.2 KiB) Downloaded 22 times

Mog
Posts: 28
Joined: Tue Dec 04, 2018 4:01 am
languages_spoken: english
ODROIDs: ODroid Go
Location: North Yorkshire, United Kingdom
Contact:

Re: Improving screen response

Unread post by Mog » Wed Dec 19, 2018 10:18 am

~Yoink~

Thanks for building these, I don't suppose you could point me at the howto for setting up the build environment? I understand I must use a patched one and I need to add keyboard support to the spectrum emulator as the author is I think busy with his studies... (I have both windows 10 and debian 9 machines at my disposal)

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 10:41 am

Mog wrote:~Yoink~

Thanks for building these, I don't suppose you could point me at the howto for setting up the build environment? I understand I must use a patched one and I need to add keyboard support to the spectrum emulator as the author is I think busy with his studies... (I have both windows 10 and debian 9 machines at my disposal)
I'm not Mog, but I'll try to answer anyway :)

I develop under WSL (Ubuntu) on Windows and on Mac OS-X, though I find USB serial works way better on the former (even under WSL!). First you want to install the ESP32 toolchain: https://docs.espressif.com/projects/esp ... -toolchain

After getting that done, follow the instructions for installing esp-idf, but instead of the official repository, clone crashoverride's: https://github.com/OtherCrashOverride/esp-idf

And then you're basically good to go - note though, that my work requires the SPI code from at least the 3.2 branch of the official ESP-IDF repository. You can just copy the files from the official repository over crashoverride's, they build fine without any external changes. Those files are:

Code: Select all

components/driver/include/driver/spi_common.h
components/driver/include/driver/spi_master.h
components/driver/spi_common.c
components/driver/spi_master.c
components/driver/spi_slave.c
These are required for polling transaction support. I tried using Geek Workbench's branch of esp-idf which is master with crashoverride's changes rebased on top, but I found there were other issues (documented earlier in this thread), so I'm sticking with this as I don't have the time or knowledge right now to debug that. I guess you could probably just build the SPI code externally and then not require idf changes, but this was easier and quicker for me.

To build a project, first go into the particular subdirectory and change the sdkconfig and flashapp.sh script to point to your particular USB serial device (it defaults to /dev/ttyUSB0, but mine is /dev/ttyS4 on WSL, for example). Then just type 'make' (or if you want it to complete faster, 'make -j4') and with the device plugged in to the computer and turned on, run flashapp.sh (which will overwrite the application on your device). Note, do *not* run 'make flash', as that will leave your device unusable until you re-flash a valid firmware.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Wed Dec 19, 2018 10:58 am

To produce a .fw file, an application graphic "tile" will need to be created and the 'mkfw' utility from the odroid-go-firmware repository used.
https://github.com/OtherCrashOverride/o ... tools/mkfw

Mog
Posts: 28
Joined: Tue Dec 04, 2018 4:01 am
languages_spoken: english
ODROIDs: ODroid Go
Location: North Yorkshire, United Kingdom
Contact:

Re: Improving screen response

Unread post by Mog » Wed Dec 19, 2018 3:37 pm

Ahh, thankyou CWiiis and Nemo1984

That was all pretty painless and the hello world example specified builds but when I go to flashapp.sh there is no such script anywhere in my home directory or path, have I missed something out?

Tried using make flash and that worked okay and sent the app to the device (overwriting the firmware selector of course but then so does the Arduino software every time I attempt to do anything without converting it to a .fw first so I'm used to it and the reflashing afterwards), can also create .fws from the binary in the build directory off the project after compilation in much the same way as I did with the Arduino software it seems so the only thing I can't do is flashapp.sh

This definitely seems worlds ahead of what I got in the Arduino software, the various options I see in make menuconfig look interesting (and like I could have more control over how much heap the RTOS is eating)

Thankyou again!

User avatar
mad_ady
Posts: 5428
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: Improving screen response

Unread post by mad_ady » Wed Dec 19, 2018 4:01 pm

You can steal and edit the flashapp.sh from other projects. It just erases the flash and writes the compiled app

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 8:35 pm

So I've been thinking of what to do to improve SMS performance as it really isn't anywhere where I want it to be - currently it's using the same interlace-fallback settings as NES, but they don't suit it as the emulator doesn't perform as well, so it falls back far too often. This can be adjust for a nicer visual experience, but it isn't going to improve the framerate. Something the emulator does, which is the same in the NES emulator, is that all timing is done by waiting on the audio streaming. That's fine, but it's a hard wait - so you essentially have:

Core 1:
Read inputs
Emulate system frame
{Calculate buffer diff for screen update
Send screen update information to core 2 (and possibly wait if it's still transferring)} - these are skipped if we get behind
Send audio to DAC and wait

Core 2:
Receive screen update
Push screen update to screen

Because audio output is synchronous, time that could be spent emulating the next frame is spent essentially just waiting. This is the same on the NES emulator, but that emulator is so much faster it doesn't really become an issue (though an improvement may still help, I've not timed each stage exactly). Ideally the audio would work in the same way as the video - sending it is asynchronous and we'd only wait for it if we get ahead by a frame. This would give us less idle time and decrease any possible wait for getting a screen update out (which is the real bottleneck once issues like this are fixed). We don't ever want the SPI bus to be idle when it could be pushing video data out. Doing audio asynchronously and letting it get a frame ahead would essentially increase input latency (in the pathological worst case, up to a frame), so there is a trade-off. I think in most cases, however, the increased fluidity of frame delivery will be a net benefit to control response. I'm going to experiment with this next, I'd really like to see a game like Sonic run at 50fps+ in unscaled mode, much like Mario Brothers and Contra on the NES.

crashoverride
Posts: 4317
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: Improving screen response

Unread post by crashoverride » Wed Dec 19, 2018 9:30 pm

Cwiiis wrote:Because audio output is synchronous, time that could be spent emulating the next frame is spent essentially just waiting.
It just looks that way because esp-idf handles the DMA. You can tune the audio buffer settings to allocate more or less space to achieve the amount of latency desired. The "sweet spot" is currently room for 1/30s since the frame rate is fixed. With a dynamic frame rate, you will need to calculate "worst case" based on the longest video frame time expected.
https://github.com/OtherCrashOverride/g ... .c#L63-L65

[edit]
It is also possible to make audio non-blocking by changing the timeout value:
https://github.com/OtherCrashOverride/g ... dio.c#L222

[edit2]
Since there is no VSYNC, the audio is used to rate-limit the emulators to 60fps. This is the rational behind the use of blocking.

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Wed Dec 19, 2018 9:46 pm

crashoverride wrote:
Cwiiis wrote:Because audio output is synchronous, time that could be spent emulating the next frame is spent essentially just waiting.
It just looks that way because esp-idf handles the DMA. You can tune the audio buffer settings to allocate more or less space to achieve the amount of latency desired. The "sweet spot" is currently room for 1/30s since the frame rate is fixed. With a dynamic frame rate, you will need to calculate "worst case" based on the longest video frame time expected.
https://github.com/OtherCrashOverride/g ... .c#L63-L65

[edit]
It is also possible to make audio non-blocking by changing the timeout value:
https://github.com/OtherCrashOverride/g ... dio.c#L222

[edit2]
Since there is no VSYNC, the audio is used to rate-limit the emulators to 60fps. This is the rational behind the use of blocking.
Thanks, that's super useful :)

I implemented what I suggested, which is essentially a really inefficient way of increasing the buffer size slightly, I suppose and it helped a little - but the SMS emulator is just so close to spending the whole frame working to keep up that almost any extra work causes it to go over the frame budget. I think I need to look at other ways of reducing the amount of indirection in the emulator so there's a bit more memory bandwidth available...

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Thu Dec 20, 2018 1:36 am

I tweaked the buffer values to numbers that fit better with the size of the buffers that are going in, and that helped a little with that, and I also added a 32-bit fast-path to buffer diffing, which helped a lot, but the SMS emulator is just running too near capacity at 60Hz to do anything else useful right now. I'm going to search for places I can reduce on copying, but I'm also toying with the idea of splitting the video update into two tasks and doing the buffer diffing on the second core in parallel with upload of the last frame. I'm not sure if this will help or not, but assuming I can't find other areas to save time on the first core, it's worth a shot.

The bright side of this is that the optimisation work for SMS has improved NES a little bit again, to the point where interlaced mode is *very* close to running at 60Hz unscaled, even in the worst of scenes. I've left interlacing off for the SMS for now as it really doesn't help significantly just yet. Some SMS games actually work quite nicely (Asterix, for example), but Sonic is kind of my benchmark because I love that game so I want to see that working at a decent rate.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Thu Dec 20, 2018 7:24 am

You're gonna get these emus flying!
Test firmware updated. Nes and SMS emu come from Cwiis, GNUboy from the official firmware.
Attachments
TEST_NES_SMS_20181219.zip
Unofficial build
(1009.58 KiB) Downloaded 54 times

metagod194041
Posts: 8
Joined: Fri Dec 14, 2018 10:23 pm
languages_spoken: english
ODROIDs: Odroid Go
Contact:

Re: Improving screen response

Unread post by metagod194041 » Thu Dec 20, 2018 6:00 pm

Great job Nemo1984! I hope there are more active development for the GO.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Thu Dec 20, 2018 10:43 pm

metagod194041 wrote:
Thu Dec 20, 2018 6:00 pm
Great job Nemo1984! I hope there are more active development for the GO.
It's not me, it's all Cwiis. I'm just building the firmware.

kcoles
Posts: 32
Joined: Mon Oct 01, 2018 12:14 am
languages_spoken: english
ODROIDs: go
Contact:

Re: Improving screen response

Unread post by kcoles » Sat Dec 29, 2018 7:41 am

Found some issues with saving on NES. Occasionally I will come out by hitting the exit button and the screen will freeze with an hour glass and the rom save file on the card will be at zero bytes. On any further attempting to save it just does the same. Deleting the save file recovers it however it happens again on the next second save. Note that Bomberman 2 does it consistently if you want to check.

Going back to the official rom has solved this and its stable again. Could you look at this as your new fw runs very well but saving is obviously paramount.

Thanks,

Keith.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Sat Dec 29, 2018 7:45 am

kcoles wrote:
Sat Dec 29, 2018 7:41 am
Found some issues with saving on NES. Occasionally I will come out by hitting the exit button and the screen will freeze with an hour glass and the rom save file on the card will be at zero bytes. On any further attempting to save it just does the same. Deleting the save file recovers it however it happens again on the next second save. Note that Bomberman 2 does it consistently if you want to check.

Going back to the official rom has solved this and its stable again. Could you look at this as your new fw runs very well but saving is obviously paramount.

Thanks,

Keith.
You are right. I can reproduce it quite easily. Furthermore, going back to default firmware won't fix it, you have to delete the .sav manually.

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Sat Dec 29, 2018 7:56 am

If I can find the ROM I'll take a look, though probably not until next week at this point. Funny that it reproduces in a particular game, I bet that'll be some interesting debugging!

kcoles
Posts: 32
Joined: Mon Oct 01, 2018 12:14 am
languages_spoken: english
ODROIDs: go
Contact:

Re: Improving screen response

Unread post by kcoles » Sun Dec 30, 2018 9:57 am

Its mainly due to that being he one im working through atm so it was the most prevelant. There were a few others but didnt pay attention. It doesnt happen on the official fw so maybe crashoveride has come across this?

crashoverride
Posts: 4317
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: Improving screen response

Unread post by crashoverride » Sun Dec 30, 2018 11:12 am

kcoles wrote:
Sun Dec 30, 2018 9:57 am
It doesnt happen on the official fw so maybe crashoveride has come across this?
The most relevant advice I can offer is that all LCD SPI transactions must be completed and halted before SD card SPI operations can be used. This is due to the SD SPI driver design in esp-idf (software issue).

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Fri Jan 04, 2019 3:05 am

Debugging it, looks like malloc is failing when saving the file, must be pretty close to the memory limits - I'll see if it'll work using SPI ram, or if there's some memory we can free beforehand. Alternatively, might just be able to tweak some stack sizes here and there.

Cwiiis
Posts: 49
Joined: Wed Nov 21, 2018 10:08 pm
languages_spoken: english
ODROIDs: ODROID Go
Contact:

Re: Improving screen response

Unread post by Cwiiis » Fri Jan 04, 2019 3:34 am

I've just pushed a possible fix - I don't have the ROM that most easily reproduces this error, but there was a very easy and substantial memory-use win and things are reliable on the roms I've tried. There's another easy win there again if there are still issues.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Fri Jan 04, 2019 7:34 am

Updated test firmware.

This seems to work with Bomberman II. I tested it 10 times without crash.

Nice work!
Attachments
TEST_NES_SMS_20190103.zip
Unofficial build
(1008.54 KiB) Downloaded 71 times

kcoles
Posts: 32
Joined: Mon Oct 01, 2018 12:14 am
languages_spoken: english
ODROIDs: go
Contact:

Re: Improving screen response

Unread post by kcoles » Sat Jan 12, 2019 7:39 pm

Cwiiis wrote:
Fri Jan 04, 2019 3:34 am
I've just pushed a possible fix - I don't have the ROM that most easily reproduces this error, but there was a very easy and substantial memory-use win and things are reliable on the roms I've tried. There's another easy win there again if there are still issues.
Many thanks. Am in awe at how quickly you've fixed it :-)

metagod194041
Posts: 8
Joined: Fri Dec 14, 2018 10:23 pm
languages_spoken: english
ODROIDs: Odroid Go
Contact:

Re: Improving screen response

Unread post by metagod194041 » Mon Jan 14, 2019 4:24 pm

Nemo1984 wrote:
Fri Jan 04, 2019 7:34 am
Updated test firmware.

This seems to work with Bomberman II. I tested it 10 times without crash.

Nice work!
Hi, when I tested StarTropics on NES, vertical screen tearing is unbearable :( This is my first try for the game tho, may be it was already like that in the original GoPlay?

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Wed Jan 23, 2019 5:39 am

metagod194041 wrote:
Mon Jan 14, 2019 4:24 pm
Nemo1984 wrote:
Fri Jan 04, 2019 7:34 am
Updated test firmware.

This seems to work with Bomberman II. I tested it 10 times without crash.

Nice work!
Hi, when I tested StarTropics on NES, vertical screen tearing is unbearable :( This is my first try for the game tho, may be it was already like that in the original GoPlay?
It might be because of the interlacing that was added in the firmware. The original doesn't have interlacing, but you will have screen tearing.

Nothing is perfect I guess.

amstradcpc
Posts: 4
Joined: Mon Sep 10, 2018 7:54 pm
languages_spoken: english
ODROIDs: Odroid-GO
Contact:

Re: Improving screen response

Unread post by amstradcpc » Thu Jan 24, 2019 11:15 pm

Mog wrote:
Sun Dec 16, 2018 4:04 am
I'm in the process of porting RunCPM to it so we can run 40 year old software like Wordstar with the keyboard, it works over the serial atm, and 40/53 columns looks okay but 80 requires a 4x8 font which would have been more readable with subpixel rendering, however due to it being a portrait screen the subpixels are rotated 90 degrees from what I need, heh.
Hi,

any news about your RunCPM port ?

lordhardware
Posts: 59
Joined: Sat Sep 20, 2014 11:56 pm
languages_spoken: english
ODROIDs: U3
Odroid-W
Contact:

Re: Improving screen response

Unread post by lordhardware » Fri Jan 25, 2019 10:55 am

So i've tested a fair few games on NES and so far it's night and day, games that were unplayable if you were familiar with them are now enjoyable on the go.

On the SMS its a mixed bag, the games that emulated better to start with seem a little less jagged maybe a little smoother hard to say. Other games that have slowdown issues in the Emu seem the same if not a little worse because of the interlacing.

gogogadget
Posts: 5
Joined: Sun Jul 01, 2018 4:47 pm
languages_spoken: english
ODROIDs: odroid-go
Contact:

Re: Improving screen response

Unread post by gogogadget » Sat Jan 26, 2019 7:01 pm

I have tested some nes and game gear games qnd I found the improvement is really there! well done!
Would it be possible to apply the same optimisations to GB and GBC? It would really improve the experience!

Mog
Posts: 28
Joined: Tue Dec 04, 2018 4:01 am
languages_spoken: english
ODROIDs: ODroid Go
Location: North Yorkshire, United Kingdom
Contact:

Re: Improving screen response

Unread post by Mog » Sat Jan 26, 2019 11:46 pm

amstradcpc wrote:
Thu Jan 24, 2019 11:15 pm
Mog wrote:
Sun Dec 16, 2018 4:04 am
I'm in the process of porting RunCPM to it so we can run 40 year old software like Wordstar with the keyboard, it works over the serial atm, and 40/53 columns looks okay but 80 requires a 4x8 font which would have been more readable with subpixel rendering, however due to it being a portrait screen the subpixels are rotated 90 degrees from what I need, heh.
Hi,

any news about your RunCPM port ?
I'll try to get to it when I have more time, other problems atm, I need to write a decent console library that isn't horribly slow and supports vt100, this will be useful for other things too but isn't as easy as it sounds.. CP/M itself is working as is (the standard RunCPM code only requires changes to use the correct lines for the SD then it just works, had wordstar, mbasic and a few infocom games running on it) so it is just a console library needed.

Zockeromi
Posts: 18
Joined: Sat Feb 16, 2019 4:50 pm
languages_spoken: english
ODROIDs: odroid go
Contact:

Re: Improving screen response

Unread post by Zockeromi » Tue Feb 19, 2019 1:47 am

This is a great improvement! Now i would like to see this fw and the johannes-behr fw merged, because the save state solution, the ms emulation improvement and the different gameboy comor palettes are really great as well. Any chance?

User avatar
GldRush98
Posts: 20
Joined: Wed Aug 08, 2018 12:58 am
languages_spoken: English
ODROIDs: ODROID-Go
Contact:

Re: Improving screen response

Unread post by GldRush98 » Mon Feb 25, 2019 10:25 am

Zockeromi wrote:
Tue Feb 19, 2019 1:47 am
This is a great improvement! Now i would like to see this fw and the johannes-behr fw merged, because the save state solution, the ms emulation improvement and the different gameboy comor palettes are really great as well. Any chance?
+1 This would be pretty fantastic.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Mon Feb 25, 2019 11:09 am

GldRush98 wrote:
Mon Feb 25, 2019 10:25 am
Zockeromi wrote:
Tue Feb 19, 2019 1:47 am
This is a great improvement! Now i would like to see this fw and the johannes-behr fw merged, because the save state solution, the ms emulation improvement and the different gameboy comor palettes are really great as well. Any chance?
+1 This would be pretty fantastic.
That would be amazing.

Nemo1984
Posts: 95
Joined: Thu Aug 23, 2018 7:58 pm
languages_spoken: english, french
ODROIDs: Odroid-Go
Contact:

Re: Improving screen response

Unread post by Nemo1984 » Wed Mar 06, 2019 9:32 am

Nemo1984 wrote:
Mon Feb 25, 2019 11:09 am
GldRush98 wrote:
Mon Feb 25, 2019 10:25 am
Zockeromi wrote:
Tue Feb 19, 2019 1:47 am
This is a great improvement! Now i would like to see this fw and the johannes-behr fw merged, because the save state solution, the ms emulation improvement and the different gameboy comor palettes are really great as well. Any chance?
+1 This would be pretty fantastic.
That would be amazing.
Done:
viewtopic.php?p=248327#p248327

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: Baidu [Spider] and 0 guests