Comments (47)
Wow this is fantastic! Many thanks to both of you!
Now the settlers can have a map size of 7 instead of 5. For size 8, 68030+ is actually needed. But this is a very good start!
An amusing minor issue: my older snapshots are not marked as obsolete, but nothing happens if I try to load them. I created a new Settlers 020 snapshot... which fails to reload (see nonsense reason attached) :)
from vamigaweb.
An amusing minor issue: my older snapshots are not marked as obsolete
fixed and pushed to uat
from vamigaweb.
Great, thanks a lot!
from vamigaweb.
new version without 68020 instruction logging pushed to uat
from vamigaweb.
Great, thanks, works fine now!
from vamigaweb.
restored cpu type in settings from a snapshot load
and removed the @=
in front of cpu clock
pushed to uat environment (https://vamigaweb.github.io/uat/)
from vamigaweb.
Great idea, thanks!
from vamigaweb.
I restored snapshots from the previous version.
Settlers works fine.
Interceptor starts to work fine for a few seconds, then black screen!! Any clue? Cheers
from vamigaweb.
Interceptor starts to work fine for a few seconds, then black screen!! Any clue?
with the 68000 oder 68020 ? I mean what was inside the snapshot, which type of cpu?
If 68020 then maybe still some bug in restoration of the internal CPU state? I see some more commits on vAmiga which I have not yet merged into vAmigaWeb ...
this one
from vamigaweb.
Yes, 68020 for everything...
from vamigaweb.
Yes, 68020 for everything...
ok ... too new stuff 😅 ... just merging in the latest commits from dirk...
from vamigaweb.
merged latest commits from vAmiga (no 68030 yet) but probably more stable than the code base from three days ago
pushed to uat
from vamigaweb.
Now both previous snapshots reset the amiga and reload their floppy or hdd! :)
from vamigaweb.
That is because the internal structure of the snapshot has changed. There were this missing CPU stuff mentioned above. (Which caused probably the issue after restoring snapshot of interceptor. ) Therefore it cannot load it anymore. I did not increased the version therefore also no compatibility warning. Uat version is only for tests.
from vamigaweb.
Ok, understood, thanks!
from vamigaweb.
Restoring the Interceptor snapshot now works (after recreating the snapshot) but the initial screen in viewport tracking mode seems distorted (it gets OK on the next screen). Strange...
from vamigaweb.
but the initial screen in viewport tracking mode seems distorted (it gets OK on the next screen). Strange...
what exactly means distorted ?
I tried interceptor with 68020 to reproduce it and what I see on iPhone after snapshot restoring in viewport tracking
or borderless
is that it calibrates the visible screen size for some fractions of a second ... Is it that what you mean with distorted ?
from vamigaweb.
No, it is more than calibration, only the first screen is like that for as long as you don't touch the keyboard, once you do the second screen comes in with normal calibration and size, see the difference with previous screenshot. It is the first time I see this...
from vamigaweb.
see the difference with previous screenshot.
I don't get it ... I literally searched minutes for something odd on the pictures above ... I mean I can not see the distortion in your picture nor the difference... can you describe with words what you think is wrong ?
from vamigaweb.
The first picture is much taller, the letters are quite stretched vertically
from vamigaweb.
Ah ok, I understand now ...
reproduced it and now I see it too ...
=> that happens only in borderless
and not in viewport tracking
and it is quite intentional what happens here... I mean I have programmed it that way...
test case: load it from start
when you load with borderless
from the beginning then the calibration already takes the bigger width of the screen (which it saw on the title screen of interceptor) into its calculation and the mentioned screen shot above is not stretched vertically.
test case: load it from a snapshot, where there is not much drawn on the left and right border sides of the screen
- on snapshot load:
borderless
resets its calculation, it sees now a very narrow screen and cuts the borders off... - when you press a key for the next screen (which is wider) then
borderless
sees and learns that there is more used screen width and adapts to it
bottom line: when using bordeless
it does not care on the correct aspect ratio
but tries to eliminate the borders instead (the extend of border elimination is constrained to the max screen borders it already discovered while executing the game)
its kind of a trade off ... borderless
when your device has a tiny screen size (to see it as big as possible) and all the others modes when you are on big screen. On big screen maybe the nicest is standard
then you see at least some borders
from vamigaweb.
Ok, thanks a lot! I thought it was the first time I see it that way... Maybe because my snapshot starts from the intro scren, not the intro image as before...
Cheers
from vamigaweb.
Maybe because my snapshot starts from the intro screen, not the intro image as before...
exactly...
also when loading with borderless
until the mentioned screen then it looks nice because it learned already that the screen can be bigger ... then when you switch to standard
it forgets/resets the learned boundaries and when you switch back to borderless
again it is too tall on that particular game screen
What could be done is to not reset borderless
when switching the modes and also to save the learned boundaries into the snapshot ... I don't know whether I should do that ... Maybe one wants to reset the learned boundaries? I don't know ...
Or maybe a borderless but not too agressive
mode ? Which preserves/calculates the correct aspect ratio on top of the calculated borderless boundaries?
from vamigaweb.
I think the aspect ratio should always be preserved no matter what... No reason to have a distorted image! :)
from vamigaweb.
ok I see will create a separate issue ...
from vamigaweb.
Great!
from vamigaweb.
pushed to uat
from vamigaweb.
Wow!! Goal is reached at last!! Congrats and tanks to all of you on this idea!!
Now at last map size 8 on Settlers!
Settlers also mentions FPU when available but this doesn't seem to translate in any extra feature for the user...
from vamigaweb.
68030 has no internal FPU ... only 68040 starts with an embedded one I think...
concerning the crashes on sysinfo which probably does some extra extensive tests which then lead to a guru meditation ...see here dirkwhoffmann/vAmiga#732 dirk already set up toni wilens cpu tester to iron them out ... probably the crashes will then go away when dirk fixes a bunch of them
from vamigaweb.
Yes, I know about the FPU, I meant that Settlers is able to detect 68881 or 68882 but doesn't seem to do anything useful with them.
Indeed let's hope this guru meditation thing can be solved!
I have another problem... I tried to push Settlers to its limit with map size 8 and experienced sluggish sound again with a low number of frames... Even when I load the snapshot again (beginning of Settlers prior to choosing a map size) the problem remains... Even after restarting the phone!!
from vamigaweb.
Getting worse... Not only everything is saturated (to few rendered frames whatever the game, reset...) but also my Interceptor snapshot start working fine for a few seconds then... Guru meditation! This never happened before...
from vamigaweb.
And suddenly after one hour of sluggishness, now sound and speed is OK again. I didn't do anything! But the guru mediation on Interceptor snapshot is still there...
from vamigaweb.
I will looking into the speed thing on a modern i5 gen 11 laptop and watch the rendered frames under different configurations
despite that:
speed should be comparable to 68000 because it is the same way of implementation but maybe still a bit buggy or has still some sort of debug code or superfluous code paths in it ...
I wouldn't test too much by now ... it is still full of bugs and untested as dirk said
much better is it to solve all the errors which tonis cpu_tester reports ... after that it should theoretically not again guru
from vamigaweb.
I also saw a slight drop with 68030 on higher clock speeds...
running a 68030 at 7Mhz for now seems safe and ok with the current implementation ...
from vamigaweb.
I have saturation problems even with 68000 now...
Reverting to 7mhz seems to solve the frame problem...
I enabled developpers options and monitored cpu and gpu usage. Cpu is around 25% and never goes up to 50%. Fps (surface) is very high at times, not sure how to interpret...
Cheers
from vamigaweb.
Is the regular version different?
from vamigaweb.
I'm not too sure. Long time didn't use the regular version, my snapshots are not valid any more...
from vamigaweb.
I think it found the guru problem.
The Interceptor snapshot was saved with 68020.
Loading it while vAmiga is in 68030 mode triggers the guru. But changing to 68020 prior to loading avoids the guru!
In both 68020 and 68030, 7 and 14 mhz are OK most of the time, 28mhz has a lot of missed frames. Not always! Just at times. Very strange....
from vamigaweb.
great finding ... maybe snapshot restore does not correctly restore the cpu type in the describe use case and leads to the guru ... @dirkwhoffmann possibly a fault in the core ?
for the framerate drops I guess thermal throtteling is a candidate to explain the cause for it .... found a german article on the net which says that z3 fold while overall being a great phone is plagued with aggressive thermal throtteling... and it also says that one can disable some settings to partially avoid this
see
https://www.nextpit.de/samsung-galaxy-z-fold-3-test
from vamigaweb.
Wow... Many thanks aks for this, I didn't know. I'm so disappointed... You buy the flaghsip model, you pay a bomb, and you still have to deal with issues like this! I activated the "enhanced processing" option (they say it works for everything except games, I hope vAmigaWeb is not reported as a game?). Now it seems from the console that I have no frame drops. Also it is morning, the phone could cool off for the whole night, so maybe it plays a role...
Even when I have no frame drops the sound is not perfect, some glitches here and there in Settlers music... Is it the case for you as well?
Cheers
from vamigaweb.
I spoke too fast... Even with this option enabled, I'm back to heavy frame drops... :(
What I don't get is that Retroarch / puae (this again, sorry) never ever game me this. I just tried it again, so the phone is in the same state... 68030, 35Mhz cycle-exact, Settlers works like a charm in perfect sound... For the same kind of processor load, right?
from vamigaweb.
for the guru issue you found I asked dirk whether he sees something ...
for the performance thing:
-
you had this problem long before right ? And mostly with settlers?
is it much worse now ? How much ? Other game titles too ? -
can you see the cpu/fpu usage when running PUAE vs vAmigaWeb ? Maybe vAmigaWeb takes much more ? Can you also test the regular version as it was compiled with an older LLVM compiler which might do something different....
-
I will run settlers 68030 7Mhz on my iPhone with cable connected (so that it gets hot) and look how long it will take that it goes into thermal throtteling... I will report back
from vamigaweb.
- Yes I always had this problem but it used to be more on and off. Now it is almost systematic. Not that much at 7mhz (although I can happen) but mostly at 28mhz. Not only with Settlers, Interceptor too for instance.
- I tested cpu/gpu usage with developer options on vAmigaWeb and it doesn't seem to be the problem. Even during frame drops the most I got with 50% usage... I need to try again the regular version, will report.
- Noted with thanks, but better test at 28mhz I think?
from vamigaweb.
I have just tried both versions side by side in comparable situations: 68000 (only option in the regular version anyway), 28Mhz, Settlers.
In both cases I have frame drops ("rendered" sometimes goes as low as 11).
It seems to me that the regular version performs slightly better. Also, it seems the music has a different pitch (lower in the regular version), but it might only be an impression...
from vamigaweb.
After 15 minutes listening on a charging iPhone 6s 68030@7mhz with headphones connected (oh boy now I will dream of the settlers music)
no thermal throtteling....
now I will switch to 28Mhz ... we will see whether the 7 year old iPhone can handle that
from vamigaweb.
switched the same setup to 28 Mhz ...
use case with closed
debug console:
I have generally clean sound .... but with sporadic hiccups in sound every 25 seconds - 40 seconds
use case with open
debug console:
rendered fps drops immediately and constantly to 20, despite executed staying at 50 (and therefore sound buffers are filled) I hear constantly cracks/hiccups in sound
bottom line:
- open debug console eats a certain amount of power too !!
- old ancient iPhone does its job still quite well
- why are there cracks in sound under
pressure
when the audio buffers are filled ? Maybe the total of audio samples in 1000ms are coming in but the they are not evenly scheduled over time ... i.e. sometimes a big chunk and then some gap (all within that 1000ms) ?
from vamigaweb.
Ah, thanks, so it is pretty consistent with my findings! Maybe not Z3's fault after all! :)
Yes I also found that closing the console helps a bit, but definitely not enough...
from vamigaweb.
Related Issues (20)
- Serial port missing or not activated.. HOT 24
- directly boot from local storage via URL/JSON parameters HOT 4
- vamigaweb.github.io no longer boots certain ROMs after 3-4 update HOT 2
- BT Mouse - RMB (Secondary Button) Not Work iPadOS [FIXED: Update iPadOS to 16.5] HOT 5
- Incorrect Filename Save DF0 or DH0 If Both Mounted HOT 2
- LMB / Fire Btn Stuck On When Switch Between Apps
- 'Error: undefined' if a second HDF is mounted HOT 16
- Dark Bottom Bar not activated on launch... HOT 2
- Cannot load vAmigaWeb in iFrame if on same domain (Chromium specific?) HOT 18
- When using a HDF with WB the filedates are wrong HOT 5
- Onscreen Keyboard Issue HOT 3
- iPad Keyboard Issue HOT 9
- iPad Keyboard Issue HOT 1
- next to the INTL virtual keyboard support also the US version HOT 6
- Insert media eg DF0 popup touch also registers as LMB in emu... HOT 5
- vAmigaWeb runs on Apple Vision Pro HOT 13
- Warp button in the bottom player icon bar HOT 1
- action button enhancements HOT 23
- Active mouse and joystick signals stay open when bringing the app to background HOT 2
- add vAmiga activity monitors HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vamigaweb.