You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(30) |
Nov
(78) |
Dec
(203) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(82) |
Feb
(158) |
Mar
(203) |
Apr
(226) |
May
(143) |
Jun
(97) |
Jul
(35) |
Aug
(87) |
Sep
(113) |
Oct
(159) |
Nov
(97) |
Dec
(96) |
2003 |
Jan
(230) |
Feb
(146) |
Mar
(131) |
Apr
(108) |
May
(157) |
Jun
(58) |
Jul
(19) |
Aug
(21) |
Sep
(44) |
Oct
(29) |
Nov
(28) |
Dec
(57) |
2004 |
Jan
(45) |
Feb
(26) |
Mar
(58) |
Apr
(50) |
May
(39) |
Jun
(27) |
Jul
(39) |
Aug
(14) |
Sep
(44) |
Oct
(73) |
Nov
(17) |
Dec
(14) |
2005 |
Jan
(19) |
Feb
(89) |
Mar
(53) |
Apr
(16) |
May
(76) |
Jun
(38) |
Jul
(6) |
Aug
|
Sep
(24) |
Oct
(7) |
Nov
(29) |
Dec
(23) |
2006 |
Jan
(57) |
Feb
(27) |
Mar
(8) |
Apr
(17) |
May
(16) |
Jun
(15) |
Jul
(19) |
Aug
(99) |
Sep
(23) |
Oct
(7) |
Nov
(14) |
Dec
(11) |
2007 |
Jan
(9) |
Feb
(11) |
Mar
(13) |
Apr
(9) |
May
(8) |
Jun
(10) |
Jul
(14) |
Aug
(3) |
Sep
(9) |
Oct
(11) |
Nov
(2) |
Dec
(3) |
2008 |
Jan
(1) |
Feb
(7) |
Mar
(1) |
Apr
(2) |
May
(9) |
Jun
(7) |
Jul
(3) |
Aug
|
Sep
(8) |
Oct
(2) |
Nov
(8) |
Dec
(10) |
2009 |
Jan
(50) |
Feb
(55) |
Mar
(114) |
Apr
(9) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(12) |
Sep
(8) |
Oct
(16) |
Nov
(2) |
Dec
(5) |
2010 |
Jan
(19) |
Feb
(45) |
Mar
(14) |
Apr
(4) |
May
(4) |
Jun
(12) |
Jul
(9) |
Aug
(6) |
Sep
(1) |
Oct
(5) |
Nov
(33) |
Dec
(5) |
2011 |
Jan
(2) |
Feb
|
Mar
(40) |
Apr
(5) |
May
(21) |
Jun
(1) |
Jul
(5) |
Aug
(3) |
Sep
(32) |
Oct
(13) |
Nov
(1) |
Dec
(4) |
2012 |
Jan
(3) |
Feb
(7) |
Mar
|
Apr
|
May
(7) |
Jun
(4) |
Jul
(15) |
Aug
(6) |
Sep
(13) |
Oct
(1) |
Nov
(19) |
Dec
(6) |
2013 |
Jan
(11) |
Feb
(2) |
Mar
(4) |
Apr
(6) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(1) |
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(10) |
May
(22) |
Jun
|
Jul
(2) |
Aug
(7) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
(17) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2019 |
Jan
|
Feb
(9) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Manuel B. <man...@gm...> - 2024-09-22 10:39:32
|
Hi all, See the announcement on our website: http://openmsx.org/ -- Grtjs, Manuel PS: MSX FOR EVER! (Questions?http://faq.msxnet.org/ ) PPS: Visit my homepage athttp://manuel.msxnet.org/ |
From: Manuel B. <man...@gm...> - 2023-09-03 10:38:52
|
Hi all, See the announcement on our website: http://openmsx.org/ -- Grtjs, Manuel PS: MSX FOR EVER! (Questions?http://faq.msxnet.org/ ) PPS: Visit my homepage athttp://manuel.msxnet.org/ |
From: Manuel B. <man...@gm...> - 2023-07-25 21:08:19
|
Hi all, See the announcement on our website: http://openmsx.org/ Will be updated later when I get the Windows binaries :) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions?http://faq.msxnet.org/ ) PPS: Visit my homepage athttp://manuel.msxnet.org/ |
From: Manuel B. <man...@gm...> - 2023-06-28 07:41:08
|
Hi all, We're planning to release soon. If there's anything you need to push, do it now or wait until after the release. I'd there's any issue you think is critical to fix, please let me know a.s.a.p. Draft release notes are on GitHub, review much appreciated. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions?http://faq.msxnet.org/ ) PPS: Visit my homepage athttp://manuel.msxnet.org/ |
From: Manuel B. <man...@gm...> - 2022-06-12 14:40:40
|
Hi all, There will soon be an announcement on our website: http://openmsx.org/ Currently waiting for all binaries to have been built. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions?http://faq.msxnet.org/ ) PPS: Visit my homepage athttp://manuel.msxnet.org/ |
From: Manuel B. <man...@gm...> - 2021-05-18 20:44:08
|
Hi all, There will soon be an announcement on our website: http://openmsx.org/ Currently waiting for all binaries to have been built. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ |
From: Manuel B. <man...@gm...> - 2020-08-25 22:40:41
|
Hi all, There will soon be an announcement on our website: http://openmsx.org/ Currently waiting for all binaries to have been built. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ |
From: Manuel B. <man...@gm...> - 2019-03-11 21:58:25
|
Hi, On 11-03-2019 22:33, Eric Boon wrote: >> OBut whatever we do with these settings, MSX pixels will of course >> never end up outside of the "tube". That's physically impossible. > > Incorrect. Also on the real CRT it is possible to stretch up the MSX > image such that the outermost pixels fell outside the visible screen. I meant that these pixels would then be invisible. They do not end up physically outside of the tube :) So those should not be displayed in the openMSX output window. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ |
From: Eric B. <er...@er...> - 2019-03-11 21:33:56
|
Hi, > OBut whatever we do with these settings, MSX pixels will of course never end up outside of the "tube". That's physically impossible. Incorrect. Also on the real CRT it is possible to stretch up the MSX image such that the outermost pixels fell outside the visible screen. Cheers, Eric -- Eric Boon * embedded software consultancy & development Jakob-Hagenbucher-Str 8B, 80993 München * +49 176 29751361 www.ericboon.com |
From: Manuel B. <man...@gm...> - 2019-03-11 20:22:58
|
Hi, For some reasons I'm not receiving the openmsx-devel e-mails anymore on my msxnet.org account, so I missed the discussion and cannot even reply to the original e-mails. Nevertheless, as the topic is very interesting, I'd like to express my own view on some things. Below is basically a summary of what I tried to explain to mth on IRC last night... If I put things not as clear as last night, feel free to improve my wording, Maarten! :) First of all: I am not against any fancy scaling stuff or whatever. It definitely has its uses in some cases and it can also be just fun. But the biggest requirement for me is that the *default* screen output should be as realistic as possible. That's the goal of our project, so that shouldn't be a surprise. So, what is realistic? I think by default to emulate a CRT 4:3 RGB monitor would be realistic. And from that starting point I think I'd get to the following ideas: - the area where MSX pixels will be rendered is always a fixed 4:3 piece of host screen (representing "the tube" of the CRT) - we make a distinction of how MSX pixels end up on the "tube" and how the "tube" ends up in the host PC monitor Let's first look at the MSX pixels on the "tube": - the "tube" simply evenly spreads all output lines belonging to a single frame of the VDP vertically on the output area - 50/60 Hz changes of course have effect of how these pixels are spread over this "tube", just like a real monitor (less lines means more distance between lines on the "tube", etc.) - most people like to change the aspect ratio of the MSX image, for instance to make circles look like circles, to remove large black borders on MSX1 PAL output or to see all graphics when overscan is used. For that a real monitor has knobs to change the vertical and horizontal size of the MSX image on the "tube". The 'vertical' knob in one extreme shows no top/bottom borders at all and in the other extreme you get very large borders. Similar for the horizontal knob, we have all used such a monitor, haven't we? So, we need settings to manipulate the image in the same way on our "tube" as we do on a real monitor. But whatever we do with these settings, MSX pixels will of course never end up outside of the "tube". That's physically impossible. Now let's see how this "tube" ends up on the host monitor: - I can't stress it enough: the "tube" always remains its original 4:3 aspect ratio (you can't deform your real monitor either!) - Similar for window resizing: the "tube" should keep its aspect ratio, surplus areas (typically at the left/right sides) are black and could be used for OSD stuff. Of course the tube will scale with the size of the window, as long as it's always completely visible and in the right aspect ratio. - Full-screen is just a special case of resizing the window to the maximum. - Scale-factor just means how large the tube will be displayed on the host monitor. There is no reason for the scale factor to be integer. In fact, resizing the window could perhaps be a way to change the scale-factor. Tricky stuff with this proposed default mode: - low resolution host displays. They might need to fall back to a simpler scaler like we have currently. The above ideas work best on high resolution host displays, I think. - very expensive to render in software, I suppose. I don't have a problem that it will only work on a GL capable system. - the final result is a combination of MSX->tube and tube->host monitor. The former is the trickiest, I suppose. But for MSX->tube I do think we have to think 'backwards', as was discussed in another e-mail: instead of mapping pixels to tube, we should 'find back' the color of a tube pixel based on the state of the MSX (VDP settings, etc.) and monitor ("knobs"). As such, scanlines will be automatically rendered. It's actually very much like the current TV-scaler, if I understood Maarten correctly. Other requirements/ideas regarding rendering and such: - yes, let's please also keep software rendering. I don't mind to reduce the fanciness there, but users keep proving they need it as a fallback. We have seen quite some weird issues on some machines with the SDLGL-PP renderer, unfortunately. - I would really like to be able to render OSD stuff outside the MSX area to make better use of wide screen. E.g. VU-meters, main menu buttons, RAM watches or other widgets would be much better placed outside the MSX display area. However, with flexible window sizes we do have to think how to manage/change the OSD coordinate system. Lastly: again, these ideas/requirements/designs do not necessarily have to hold for other 'modes', but I do think they should hold for the default, as explained above. OK, that's what I think of it... What do you think of these ideas? -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ |
From: Maarten t. H. <ma...@tr...> - 2019-03-09 15:26:10
|
Hi all, In this mail I'd like to summarize how the video scaling is/can be implemented. I'm writing this from memory and it's been a while since I actually worked on the video scaling code, so it's possible some of the things I write here contradict the actual code. The "scale_algorithm" setting actually selects a family of scalers: you might select "hq" with the setting and get HQ2x, HQ3x or HQ4x depending on the output surface size. When the output surface is small, you'll even get a 1:1 copy "scaler" regardless of the "scale_algorithm" setting. Typically fixed zoom factor scalers have the same zoom factor horizontally and vertically. Also typically the fixed zoom factors are integers. But when designing an interface for them, it may be better to disregard the typical case and instead give each fixed scaler a floating point horizontal scale factor and a floating point vertical scale factor. Should we assume variable zoom factor scalers can handle any scale factor, or should they be given a range? I guess we could start with any scale factor and if that leads to poor output quality for some sizes, reconsider. openMSX breaks an MSX frame into different regions: - for a single-color border it stores that color, not the pixels - the display area might consist of multiple regions with a different resolution as a result of screen splits between different modes Many scalers work by comparing pixels to their neighbours. At the edge of a region, we have to look into another region to find those neighbouring pixels. To make the resolution match, we sometimes have to expand for example a border line into pixels or blend narrow (SCREEN 0.80/6/7) pixels together. We also have a deinterlacer and deflicker filter that can be applied before the main scaling. The "scale_algorithm" setting controls the selection of scaler implementations for all of the regions of an MSX frame, but that doesn't mean the same scaler implementation is selected for all regions. Which regions exist can differ per frame. Scale factor selection should not change from one frame to another though. So I think we should pick scale factors using a typical single display region and stick to them regardless of the actual regions on each frame. The scale factors should only change when the output surface size changes or the scaler settings change. Which horizontal and vertical scale factors should we select based on user settings? A possible algorithm would be: - determine aspect ratio of source area - determine aspect ratio of destination area - determine which direction (horizontal or vertical) is limiting - select zoom factor for the limiting direction - select zoom factor for the non-limiting direction - use as many source pixels as available, pad the rest Determining the limiting direction can be done by comparing source and destination aspect ratios: if source_aspect < destination_aspect, the limiting direction is vertical. For example, when scaling from 256x212 to 1920x1080 using a scaler with fixed zoom factors: - source aspect ratio is 1.21 - destination aspect ratio is 1.78 - limiting direction is vertical - 1080/212 = 5.09, we round that down to vertical zoom factor 5 - we select horizontal zoom factor 5 as well (no stretching) - 1080/5 = 216, so we use 212 display lines and 2 lines each from the top and bottom border - 1920/5 = 384, so we use 256 display columns and 86 pixels each from the left and right border; if the borders don't contain that many pixels, we pad them by repeating the outermost pixel I think this produces a good result for the fixed zoom factor case, but things get more complex when using a variable zoom factor algorithm. First question is what to use for the source area. In the fixed zoom factor case we should use the area left after maximum overscan is applied, but the actual amount of overscan we get is at most that, but often lower. For variable zoom factors, using the maximum overscan on the source area means we always get exactly the maximum overscan in the limiting direction. This is probably not what we want: maximum overscan is the largest amount we consider acceptable, not our preferred amount. What could we use instead? - a fixed overscan value, such as 224 lines, since that is more or less the highest amount of lines reliably visible when using real hardware - the actual number of display + border lines on a frame; this would lead to pretty large borders - introduce a specific setting for it - something derived from the maximum overscan setting, but not exactly equal to it For the non-limiting direction, our zoom factor becomes the limiting direction zoom factor multiplied by a stretch factor. The stretch factor must be between 1.0 and the limit set by the stretch setting. Which stretch factor we should pick depends on how many source pixels we want to use. We'd always want to use at least as many source pixels as the maximum overscan allows, but probably more than that. This is similar to the question of sizing the source area in the limiting direction. I think we need a notion of a preferred source area. If the preferred source area doesn't fit at stretch 1.0, we use stretch 1.0 and drop as many pixels as needed. Note that we will never need to drop more than the maximum overscan, since otherwise we would be the limiting direction instead. If the preferred source area does fit at stretch 1.0, we can either stretch more or increase the source area. We can increase stretch until the user-specified limit, while we can increase the source area without limit, since we'll pad the border if necessary. Since we have two variables to adjust, there are different strategies possible: A. increase source area until we run out of border, then stretch B. increase stretch first, then source area C. increase both simultaneously Option A would would lead to large borders, which is probably not what a user wants: if a user does prefer large borders, they could simply disable stretching. Option B would display the ideal source area until the maximum stretch is reached, then add more and more border (first real border, then padded border). Option C is a hybrid and depending on the exact function chosen will look more like A or B. I think what users would like is either option B, or option C with a function that puts it closer to B than A. I don't know if all these choices can actually be made in advance. Maybe we'll just have to implement some of them and see how they feel in practice. Bye, Maarten |
From: Maarten t. H. <ma...@tr...> - 2019-03-09 13:39:40
|
Hi all, A note to start with: I wrote about "integer zoom factor" algorithms in my original mail, but thinking more about it, I don't think "integer" is the crucial property there. What matters is that these algorithms support a fixed small set of scale factors, which often happen to be integer in practice, but could be non-integer as well. So I switched to the terminology of "fixed" vs "variable" zoom factor algorithms in this mail. On Wednesday, 27 February 2019 12:21:24 CET Sean Young wrote: > > 2. What pixel aspect ratio does the user like? > > > > Personally, I think pixel aspect ratio should be very close to 1:1, > > or the resulting image will look terrible. However, these are also > > users that have a different opinion and dislike large borders more > > than they dislike squished or stretch images. So we need a setting > > to please both groups. > > > > Note that some scale algorithms only support integer zoom factors, > > in which case the pixel aspect ratio must be 1:1 while that > > algorithm is active, unless a second scaling is done. > > In order to correctly overlay the msx video on laserdis, the aspect > ratio has to be different than 1:1. I'm not sure the result has too > look terrible, I assume (not presume) this can be aliased nicely with > multi sampling shaders. I may have overstated my opinion a bit; what I meant to say is that stretching for example 4:3 to 16:9 looks terrible in my opinion. In any case, if the video was originally encoded to not use square pixels, then of course it should be displayed in the same way. It's good you mentioned this, because I wasn't aware of the LD pixel aspect ratio being different from the MSX pixel aspect ratio. Since LD graphics are nowhere near as sharp as MSX graphics, I think we should have different scale algorithms for LD anyway. Something like bicubic should look decent for LD, I guess. > > In a way such settings mimic the knobs on MSX monitors for > > horizontal > > and vertical stretch. I guess that validates their existence :) > > > > Something we could consider while we're redesigning the system is > > support for non-integer scale factors. Some scale algorithms require > > integer scale factors, while others do not. Currently we restrict > > all > > algorithms to an integer vertical scale factor, while a few > > algorithms respond to a configurable horizontal stretch. We could > > support non- integer scale factors in both directions though. > > Would it be possible to have re-write e.g. RGBTriplet using > multisampling so that it can work at any scale factor? I'd say it's more like the opposite of multisampling, since the destination surface has more pixels than the source surface. > TBF I'm not entirely clear in my head how this would work. With a pixel shader, you already have to write a function that maps each destination pixel to one or more source pixels, so the main challenge is in finding the right weights for each source pixel, depending on the exact location of the destination pixel. On Wednesday, 27 February 2019 16:45:44 CET Eric Boon wrote: > On 2019-02-24 11:23, Maarten ter Huurne wrote: > > MSX screen modes are designed for 4:3 screens: 256x192 is exactly > > 4:3, 256x212 isn't that far off. > > Nonetheless, usually, MSX pixels weren't square on CRTs, but slightly > rectangular due to the top and bottom borders. I don't have references > at hand, but if you look in books and articles on the MSX-BASIC > 'CIRCLE' command, you'll find that they use a scale factor > 1 (in > SCREEN 2) to get a 'round' circle on screen. It also depends on 50Hz vs 60Hz: on 50Hz there are a lot more border lines than on 60Hz. The pixel aspect ratio for 60Hz is at least close enough to 1:1 that a 1:1 circle looks round, iirc. Maybe we can have a mode in which the user can actually see this effect in action: when you switch from 50 to 60Hz, the image should become longer. > > Setting the scale factor via the OSD console or Catapult is neither > > intuitive nor convenient. It would be much simpler for the user if > > it > > was possible to resize the openMSX output window and the scale > > factor > > would adapt automatically. > > Yes. A more sensible user setting could be how openMSX should handle > the difference in window/screen size and the MSX video image -- cf > with setting the background image on your PC desktop: > > * strech- MSX image gets stretched in both directions to fill the > window > * fit - MSX gets scaled such that it fits in the window > leaving either a top/bottom or left/rigth border > * fill - MSX image gets scaled such that it fills the window, but > either top/bottom or left/right part of the MSX image is cut off I think these are scenarios we should support, but to have those options as a setting would not be ideal. Both stretch and fill will not be very usable if the window size deviates too much from 4:3. I was thinking of having settings that put limits on the amount of stretching and overscan. So openMSX would know how much it is allowed to cut off and deform, but if it still cannot make the MSX image fit the host surface, it will pad it out by extending the border. So you could create stretch mode by setting the maximum stretch really high and you could create fill mode by setting the maximum overscan really high. How should maximum overscan be specified: - as a percentage relative to the number of display + border pixels? - as a minimum number of pixels that should be visible? Should there be separate overscan settings for horizontal and vertical? Since it's possible to actually put an image in the top/bottom border but not in the left/right border, having separate settings might be useful. In the case of visible pixels, the setting could be an absolute number or it could be an offset relative to 256/212. I think absolute is clearer; the main advantage of an offset is that it would still work when horizontal and vertical share a single setting. Note that a relative overscan would result in 50/60Hz having different vertical stretching when using a scaler that supports variable zoom factors. It wouldn't work well for fixed zoom factors though: those would put a lot of top/bottom border on 50Hz images. For maximum stretch, I think it would make sense to have a factor/ percentage setting. For example, setting it to 1.0 would mean only 1:1 pixel aspect ratio is considered acceptable. Setting it to 2.0 would mean anything between 2:1 and 1:2 is considered acceptable. Since all practically useful settings would be between 1.0 and 1.5, it would make sense to turn it into a percentage. What would be more intuitive, having 1:1 pixel aspect ratio as "100%" (original scale) or as "0%" (no stretching)? Would it be useful to have a separate maximum stretch for horizontal and vertical? My first thought is that it wouldn't be useful: such a setting expresses how tolerant you are to deformed images and I think it's unlikely people will have different tolerances for horizontal and vertical stretching. Note that fixed zoom factor scalers typically cannot stretch by small amounts, so this setting would usually have no effect while one of those is active. > > There are MSX applications that do things in the border, like > > changing colors, set adjust, vertical overscan. So the interesting > > part of an MSX > > screen is more than the 256x212 official mode size. I don't recall > > what the largest possible size is, but some of Matra's games got > > 224 visible lines with overscan, so that's a lower bound. > > Would using 640x480 as 'native' MSX screen to render to be an option? > This will always leave some border - but has simple handling of SCREEN > 6 & 7 and interlacing. > Then add a user option that switches between visible or inivisible > borders, > effectively switching between 640x480 and 512x424 (clipped) pixel > output which then gets scaled to the window size. I don't think upping the base output resolution to 640x480 would change anything: it would still work like it currently does, but with the zoom factors halved. We need to get rid of the concept of a base output resolution and instead look at how we can display the MSX screen on an arbitrary-sized host surface. I'll write a separate mail about the implementation side of things and keep this chain about the requirements. Bye, Maarten |
From: Eric B. <er...@er...> - 2019-02-27 16:16:51
|
Hi all, On 2019-02-24 11:23, Maarten ter Huurne wrote: > MSX screen modes are designed for 4:3 screens: 256x192 is exactly 4:3, > 256x212 isn't that far off. Nonetheless, usually, MSX pixels weren't square on CRTs, but slightly rectangular due to the top and bottom borders. I don't have references at hand, but if you look in books and articles on the MSX-BASIC 'CIRCLE' command, you'll find that they use a scale factor > 1 (in SCREEN 2) to get a 'round' circle on screen. > Setting the scale factor via the OSD console or Catapult is neither > intuitive nor convenient. It would be much simpler for the user if it > was possible to resize the openMSX output window and the scale factor > would adapt automatically. Yes. A more sensible user setting could be how openMSX should handle the difference in window/screen size and the MSX video image -- cf with setting the background image on your PC desktop: * strech- MSX image gets stretched in both directions to fill the window * fit - MSX gets scaled such that it fits in the window leaving either a top/bottom or left/rigth border * fill - MSX image gets scaled such that it fills the window, but either top/bottom or left/right part of the MSX image is cut off > There are MSX applications that do things in the border, like changing > colors, set adjust, vertical overscan. So the interesting part of an > MSX > screen is more than the 256x212 official mode size. I don't recall what > the largest possible size is, but some of Matra's games got 224 visible > lines with overscan, so that's a lower bound. Would using 640x480 as 'native' MSX screen to render to be an option? This will always leave some border - but has simple handling of SCREEN 6 & 7 and interlacing. Then add a user option that switches between visible or inivisible borders, effectively switching between 640x480 and 512x424 (clipped) pixel output which then gets scaled to the window size. Cheers, Eric |
From: Sean Y. <se...@me...> - 2019-02-27 11:36:42
|
Hi, On Sun, Feb 24, 2019 at 11:23:38AM +0100, Maarten ter Huurne wrote: > Hi all, > > The way openMSX currently does video scaling has some problems and when > the SDL2 transition has stabilized it might be a good time to tackle > these. Whether that is before or after releasing with SDL2 is something > I don't think we need to answer yet. Rather, I think we should have this > discussion to be able to answer that question. > > > The problems that I'm aware of: > > Resolutions are diverging a lot. We support handhelds with 320x240 > screens, while we also have users that want to run openMSX on 4K > monitors and TVs. The support for the low-res screens is working fine, > but for hi-res screens, our maximum scale factor of 4 is not enough. > > In the CRT world, full-screen mode meant a mode change to a different > native resolution: if you'd ask for 640x480, you'd get exactly 640x480 > on your monitor. In the LCD world, every screen has a native resolution. > If you output in a different resolution, your video gets scaled > automatically. However, the result of video getting scaled twice isn't > as pretty as scaling it once. > > MSX screen modes are designed for 4:3 screens: 256x192 is exactly 4:3, > 256x212 isn't that far off. However, most modern screens are 16:9 or at > least some other format that is wider than 4:3. openMSX's scaling system > is based on a 320x240 base resolution, to which an integer scale factor > can be applied. This means that if we were to introduce a scale factor > 5, this would result in a 1600x1200 output, which is too many lines for > a 1080p screen, even though the display area of the MSX screen is 212 * > 5 = 1060 lines. > > Setting the scale factor via the OSD console or Catapult is neither > intuitive nor convenient. It would be much simpler for the user if it > was possible to resize the openMSX output window and the scale factor > would adapt automatically. > > Some scalers only work at certain scale factors. If the user selects an > unsupported combination, openMSX falls back to a different scaler. > Ideally, every scaler would work at every scale factor, but in practice > that may not be an option. However, we still could consider whether a > different fallback would be more appropriate, for example falling back > to a lower scale factor (bigger borders) or doing a two-step scaling. > > The software scaling code is a pain to maintain: > - we have to write each scaler twice: once in software and once in pixel > shaders > - for good performance, we use templates than we instantiate for each > zoom factor and color depth; this both complicates the code and > increases the executable size > - the number of pixels we'd have to output for 4K is likely more than we > can render on a single core (an educated guess; I didn't benchmark it) > and scaling on multiple cores would further complicate the code > > Is there anything I missed? > > > To solve these, I think we have to redesign how scaling is done in > openMSX. At its core, what video scaling does is bridge the gap between > the MSX resolution and the native resolution of the screen on which > openMSX is displayed. > > Scaling twice isn't going to look as good as scaling once, so we should > make openMSX output at the native resolution of the screen. SDL2 has a > non-exclusive full-screen mode that fits in this model: instead of a > mode switch, it creates a screen-filling window in the native resolution > of the screen. This eliminates the delay of the mode switch: the switch > to full-screen mode becomes almost instant. > > In non-exclusive full-screen mode, SDL2 scales the application's output > to the native resolution of the screen, if necessary. We avoid this > second scaling if we make openMSX output in native resolution. However, > that means that switching from/to full-screen mode changes the scale > factor, which is not compatible with the scale factor being a setting. > > Having a resizable openMSX window on desktops means the scale factor > should change as the window becomes larger or smaller. Again, this > conflicts with the scale factor being a setting. > > So I think we need to drop the scale factor setting. Instead, we would > compute the scale factor based on the output size and some new settings. > I don't know yet what these new settings should be, but directly or > indirectly they should control two things: > > 1. Which area of the MSX screen is considered essential? > > There are MSX applications that do things in the border, like changing > colors, set adjust, vertical overscan. So the interesting part of an MSX > screen is more than the 256x212 official mode size. I don't recall what > the largest possible size is, but some of Matra's games got 224 visible > lines with overscan, so that's a lower bound. > > If we'd want to ensure 224 lines are visible, that would mean we can't > use factor 5 on 1080p, since 5 * 224 = 1120. I don't think it's a good > idea to force a scale factor of 4 on 1080p while playing for example an > MSX1 game just because there is a small amount of software that wouldn't > fit on the screen with scale factor 5. So we could have a setting that > by default doesn't consider the border area essential, but that can be > changed by the user if they do want to see what is normally border area. That's a great idea. > 2. What pixel aspect ratio does the user like? > > Personally, I think pixel aspect ratio should be very close to 1:1, or > the resulting image will look terrible. However, these are also users > that have a different opinion and dislike large borders more than they > dislike squished or stretch images. So we need a setting to please both > groups. > > Note that some scale algorithms only support integer zoom factors, in > which case the pixel aspect ratio must be 1:1 while that algorithm is > active, unless a second scaling is done. In order to correctly overlay the msx video on laserdis, the aspect ratio has to be different than 1:1. I'm not sure the result has too look terrible, I assume (not presume) this can be aliased nicely with multi sampling shaders. > In a way such settings mimic the knobs on MSX monitors for horizontal > and vertical stretch. I guess that validates their existence :) > > Something we could consider while we're redesigning the system is > support for non-integer scale factors. Some scale algorithms require > integer scale factors, while others do not. Currently we restrict all > algorithms to an integer vertical scale factor, while a few algorithms > respond to a configurable horizontal stretch. We could support non- > integer scale factors in both directions though. Would it be possible to have re-write e.g. RGBTriplet using multisampling so that it can work at any scale factor? TBF I'm not entirely clear in my head how this would work. > As I listed among the problems, software scaling isn't an option for > large scale factors. If we want to scale to native resolution and don't > want to scale twice, we must use hardware scaling. Is it feasible to > force that though? > > Hardware scaling depends on being able to run pixel shaders. Currently > we only support that via OpenGL, but there are other APIs that support > pixel shaders, such as OpenGL ES, Vulkan, DirectX and Metal. Of that > list, I think only OpenGL ES makes sense to support in the short term, > since it would allow hardware scaling on Android. Also it would require > the least amount of effort, since OpenGL ES is a subset of OpenGL. > > Hardware scaling also depends on there being an actual GPU in the > system. Devices like the Dingoo A320 and very old PCs don't have GPUs. > In my opinion it would be a shame to exclude such systems altogether, > but at the same time I don't want to put in a large amount of > maintenance effort for fringe systems. Perhaps a compromise would be to > support only 1x and 2x scaling with the "simple" algorithm on such > systems. That would allow us to remove a lot of code, but still make > ports to GPU-less systems possible. > > > So to summarize what a new system would look like: > - the user controls the output window size, via window resizing and > switching from/to full-screen mode; openMSX reacts to this by > automatically updating the scale factor > - the current scale settings (scale_factor and horizontal_stretch) are > replaced with new settings that indirectly control the computed > horizontal and vertical scale factor > - software scaling will be used only for special limited cases; for > general use we require hardware scaling > > This is of course still only a rough sketch, but I think it's useful to > have a broad idea of where we want to go before diving into details. > > Please tell me your ideas and opinions on this topic. This feature is the one thing I really miss in openmsx. All good stuff! Sean |
From: GuyveR800 <guy...@xs...> - 2019-02-24 11:13:26
|
Hi Maarten, Some of your assumptions are way off, but generally you have the right idea. Actually pseudoMSX has worked similar to this for years already. Shame that you guys keep redoing work I already did over and over again. Regards, Patriek On 24/02/2019 11:23, Maarten ter Huurne wrote: > Hi all, > > The way openMSX currently does video scaling has some problems and when > the SDL2 transition has stabilized it might be a good time to tackle > these. Whether that is before or after releasing with SDL2 is something > I don't think we need to answer yet. Rather, I think we should have this > discussion to be able to answer that question. > > > The problems that I'm aware of: > > Resolutions are diverging a lot. We support handhelds with 320x240 > screens, while we also have users that want to run openMSX on 4K > monitors and TVs. The support for the low-res screens is working fine, > but for hi-res screens, our maximum scale factor of 4 is not enough. > > In the CRT world, full-screen mode meant a mode change to a different > native resolution: if you'd ask for 640x480, you'd get exactly 640x480 > on your monitor. In the LCD world, every screen has a native resolution. > If you output in a different resolution, your video gets scaled > automatically. However, the result of video getting scaled twice isn't > as pretty as scaling it once. > > MSX screen modes are designed for 4:3 screens: 256x192 is exactly 4:3, > 256x212 isn't that far off. However, most modern screens are 16:9 or at > least some other format that is wider than 4:3. openMSX's scaling system > is based on a 320x240 base resolution, to which an integer scale factor > can be applied. This means that if we were to introduce a scale factor > 5, this would result in a 1600x1200 output, which is too many lines for > a 1080p screen, even though the display area of the MSX screen is 212 * > 5 = 1060 lines. > > Setting the scale factor via the OSD console or Catapult is neither > intuitive nor convenient. It would be much simpler for the user if it > was possible to resize the openMSX output window and the scale factor > would adapt automatically. > > Some scalers only work at certain scale factors. If the user selects an > unsupported combination, openMSX falls back to a different scaler. > Ideally, every scaler would work at every scale factor, but in practice > that may not be an option. However, we still could consider whether a > different fallback would be more appropriate, for example falling back > to a lower scale factor (bigger borders) or doing a two-step scaling. > > The software scaling code is a pain to maintain: > - we have to write each scaler twice: once in software and once in pixel > shaders > - for good performance, we use templates than we instantiate for each > zoom factor and color depth; this both complicates the code and > increases the executable size > - the number of pixels we'd have to output for 4K is likely more than we > can render on a single core (an educated guess; I didn't benchmark it) > and scaling on multiple cores would further complicate the code > > Is there anything I missed? > > > To solve these, I think we have to redesign how scaling is done in > openMSX. At its core, what video scaling does is bridge the gap between > the MSX resolution and the native resolution of the screen on which > openMSX is displayed. > > Scaling twice isn't going to look as good as scaling once, so we should > make openMSX output at the native resolution of the screen. SDL2 has a > non-exclusive full-screen mode that fits in this model: instead of a > mode switch, it creates a screen-filling window in the native resolution > of the screen. This eliminates the delay of the mode switch: the switch > to full-screen mode becomes almost instant. > > In non-exclusive full-screen mode, SDL2 scales the application's output > to the native resolution of the screen, if necessary. We avoid this > second scaling if we make openMSX output in native resolution. However, > that means that switching from/to full-screen mode changes the scale > factor, which is not compatible with the scale factor being a setting. > > Having a resizable openMSX window on desktops means the scale factor > should change as the window becomes larger or smaller. Again, this > conflicts with the scale factor being a setting. > > So I think we need to drop the scale factor setting. Instead, we would > compute the scale factor based on the output size and some new settings. > I don't know yet what these new settings should be, but directly or > indirectly they should control two things: > > 1. Which area of the MSX screen is considered essential? > > There are MSX applications that do things in the border, like changing > colors, set adjust, vertical overscan. So the interesting part of an MSX > screen is more than the 256x212 official mode size. I don't recall what > the largest possible size is, but some of Matra's games got 224 visible > lines with overscan, so that's a lower bound. > > If we'd want to ensure 224 lines are visible, that would mean we can't > use factor 5 on 1080p, since 5 * 224 = 1120. I don't think it's a good > idea to force a scale factor of 4 on 1080p while playing for example an > MSX1 game just because there is a small amount of software that wouldn't > fit on the screen with scale factor 5. So we could have a setting that > by default doesn't consider the border area essential, but that can be > changed by the user if they do want to see what is normally border area. > > 2. What pixel aspect ratio does the user like? > > Personally, I think pixel aspect ratio should be very close to 1:1, or > the resulting image will look terrible. However, these are also users > that have a different opinion and dislike large borders more than they > dislike squished or stretch images. So we need a setting to please both > groups. > > Note that some scale algorithms only support integer zoom factors, in > which case the pixel aspect ratio must be 1:1 while that algorithm is > active, unless a second scaling is done. > > > In a way such settings mimic the knobs on MSX monitors for horizontal > and vertical stretch. I guess that validates their existence :) > > Something we could consider while we're redesigning the system is > support for non-integer scale factors. Some scale algorithms require > integer scale factors, while others do not. Currently we restrict all > algorithms to an integer vertical scale factor, while a few algorithms > respond to a configurable horizontal stretch. We could support non- > integer scale factors in both directions though. > > > As I listed among the problems, software scaling isn't an option for > large scale factors. If we want to scale to native resolution and don't > want to scale twice, we must use hardware scaling. Is it feasible to > force that though? > > Hardware scaling depends on being able to run pixel shaders. Currently > we only support that via OpenGL, but there are other APIs that support > pixel shaders, such as OpenGL ES, Vulkan, DirectX and Metal. Of that > list, I think only OpenGL ES makes sense to support in the short term, > since it would allow hardware scaling on Android. Also it would require > the least amount of effort, since OpenGL ES is a subset of OpenGL. > > Hardware scaling also depends on there being an actual GPU in the > system. Devices like the Dingoo A320 and very old PCs don't have GPUs. > In my opinion it would be a shame to exclude such systems altogether, > but at the same time I don't want to put in a large amount of > maintenance effort for fringe systems. Perhaps a compromise would be to > support only 1x and 2x scaling with the "simple" algorithm on such > systems. That would allow us to remove a lot of code, but still make > ports to GPU-less systems possible. > > > So to summarize what a new system would look like: > - the user controls the output window size, via window resizing and > switching from/to full-screen mode; openMSX reacts to this by > automatically updating the scale factor > - the current scale settings (scale_factor and horizontal_stretch) are > replaced with new settings that indirectly control the computed > horizontal and vertical scale factor > - software scaling will be used only for special limited cases; for > general use we require hardware scaling > > This is of course still only a rough sketch, but I think it's useful to > have a broad idea of where we want to go before diving into details. > > Please tell me your ideas and opinions on this topic. > > Bye, > Maarten > > > > > > _______________________________________________ > openMSX-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openmsx-devel > |
From: Maarten t. H. <ma...@tr...> - 2019-02-24 10:23:49
|
Hi all, The way openMSX currently does video scaling has some problems and when the SDL2 transition has stabilized it might be a good time to tackle these. Whether that is before or after releasing with SDL2 is something I don't think we need to answer yet. Rather, I think we should have this discussion to be able to answer that question. The problems that I'm aware of: Resolutions are diverging a lot. We support handhelds with 320x240 screens, while we also have users that want to run openMSX on 4K monitors and TVs. The support for the low-res screens is working fine, but for hi-res screens, our maximum scale factor of 4 is not enough. In the CRT world, full-screen mode meant a mode change to a different native resolution: if you'd ask for 640x480, you'd get exactly 640x480 on your monitor. In the LCD world, every screen has a native resolution. If you output in a different resolution, your video gets scaled automatically. However, the result of video getting scaled twice isn't as pretty as scaling it once. MSX screen modes are designed for 4:3 screens: 256x192 is exactly 4:3, 256x212 isn't that far off. However, most modern screens are 16:9 or at least some other format that is wider than 4:3. openMSX's scaling system is based on a 320x240 base resolution, to which an integer scale factor can be applied. This means that if we were to introduce a scale factor 5, this would result in a 1600x1200 output, which is too many lines for a 1080p screen, even though the display area of the MSX screen is 212 * 5 = 1060 lines. Setting the scale factor via the OSD console or Catapult is neither intuitive nor convenient. It would be much simpler for the user if it was possible to resize the openMSX output window and the scale factor would adapt automatically. Some scalers only work at certain scale factors. If the user selects an unsupported combination, openMSX falls back to a different scaler. Ideally, every scaler would work at every scale factor, but in practice that may not be an option. However, we still could consider whether a different fallback would be more appropriate, for example falling back to a lower scale factor (bigger borders) or doing a two-step scaling. The software scaling code is a pain to maintain: - we have to write each scaler twice: once in software and once in pixel shaders - for good performance, we use templates than we instantiate for each zoom factor and color depth; this both complicates the code and increases the executable size - the number of pixels we'd have to output for 4K is likely more than we can render on a single core (an educated guess; I didn't benchmark it) and scaling on multiple cores would further complicate the code Is there anything I missed? To solve these, I think we have to redesign how scaling is done in openMSX. At its core, what video scaling does is bridge the gap between the MSX resolution and the native resolution of the screen on which openMSX is displayed. Scaling twice isn't going to look as good as scaling once, so we should make openMSX output at the native resolution of the screen. SDL2 has a non-exclusive full-screen mode that fits in this model: instead of a mode switch, it creates a screen-filling window in the native resolution of the screen. This eliminates the delay of the mode switch: the switch to full-screen mode becomes almost instant. In non-exclusive full-screen mode, SDL2 scales the application's output to the native resolution of the screen, if necessary. We avoid this second scaling if we make openMSX output in native resolution. However, that means that switching from/to full-screen mode changes the scale factor, which is not compatible with the scale factor being a setting. Having a resizable openMSX window on desktops means the scale factor should change as the window becomes larger or smaller. Again, this conflicts with the scale factor being a setting. So I think we need to drop the scale factor setting. Instead, we would compute the scale factor based on the output size and some new settings. I don't know yet what these new settings should be, but directly or indirectly they should control two things: 1. Which area of the MSX screen is considered essential? There are MSX applications that do things in the border, like changing colors, set adjust, vertical overscan. So the interesting part of an MSX screen is more than the 256x212 official mode size. I don't recall what the largest possible size is, but some of Matra's games got 224 visible lines with overscan, so that's a lower bound. If we'd want to ensure 224 lines are visible, that would mean we can't use factor 5 on 1080p, since 5 * 224 = 1120. I don't think it's a good idea to force a scale factor of 4 on 1080p while playing for example an MSX1 game just because there is a small amount of software that wouldn't fit on the screen with scale factor 5. So we could have a setting that by default doesn't consider the border area essential, but that can be changed by the user if they do want to see what is normally border area. 2. What pixel aspect ratio does the user like? Personally, I think pixel aspect ratio should be very close to 1:1, or the resulting image will look terrible. However, these are also users that have a different opinion and dislike large borders more than they dislike squished or stretch images. So we need a setting to please both groups. Note that some scale algorithms only support integer zoom factors, in which case the pixel aspect ratio must be 1:1 while that algorithm is active, unless a second scaling is done. In a way such settings mimic the knobs on MSX monitors for horizontal and vertical stretch. I guess that validates their existence :) Something we could consider while we're redesigning the system is support for non-integer scale factors. Some scale algorithms require integer scale factors, while others do not. Currently we restrict all algorithms to an integer vertical scale factor, while a few algorithms respond to a configurable horizontal stretch. We could support non- integer scale factors in both directions though. As I listed among the problems, software scaling isn't an option for large scale factors. If we want to scale to native resolution and don't want to scale twice, we must use hardware scaling. Is it feasible to force that though? Hardware scaling depends on being able to run pixel shaders. Currently we only support that via OpenGL, but there are other APIs that support pixel shaders, such as OpenGL ES, Vulkan, DirectX and Metal. Of that list, I think only OpenGL ES makes sense to support in the short term, since it would allow hardware scaling on Android. Also it would require the least amount of effort, since OpenGL ES is a subset of OpenGL. Hardware scaling also depends on there being an actual GPU in the system. Devices like the Dingoo A320 and very old PCs don't have GPUs. In my opinion it would be a shame to exclude such systems altogether, but at the same time I don't want to put in a large amount of maintenance effort for fringe systems. Perhaps a compromise would be to support only 1x and 2x scaling with the "simple" algorithm on such systems. That would allow us to remove a lot of code, but still make ports to GPU-less systems possible. So to summarize what a new system would look like: - the user controls the output window size, via window resizing and switching from/to full-screen mode; openMSX reacts to this by automatically updating the scale factor - the current scale settings (scale_factor and horizontal_stretch) are replaced with new settings that indirectly control the computed horizontal and vertical scale factor - software scaling will be used only for special limited cases; for general use we require hardware scaling This is of course still only a rough sketch, but I think it's useful to have a broad idea of where we want to go before diving into details. Please tell me your ideas and opinions on this topic. Bye, Maarten |
From: Maarten t. H. <ma...@tr...> - 2019-02-24 10:01:06
|
On zondag 24 februari 2019 09:52:48 CET Wouter Vermaelen wrote: > These renderers should not be included in daily builds. These are not > useful for users (and can only confuse them). OK, then setting the default for that feature to "disabled" would make sense. > I don't remember the last time i used these renderers for development, > but then I also haven't worked on rendering stuff for many year. If > it's easy to make these into optional (disabled by default) > components then that's fine. But I also wouldn't mind dropping them. > Maybe that's even better? We can always get them back from git. Getting things back from Git is not a good long-term strategy, since the longer the code hasn't been in the source tree, the more work it is going to be to get it working again if you need it. So I'd only be in favor of dropping them if we think we're never going to use them again. > A few of our scaling algorithm exist in the software renderer (SDL) > but not in openGL scalers (SDLGL-PP). The SDLGL-FBxx renderers could > be a workaround for that. But OTOH nobody complained about the lack > of these renderers. I think the whole scaling system is not very easy to understand for users and having these renderers as an official workaround would only solidify that complexity. If we really need the workaround, it should be done automatically inside the SDLGL-PP renderer, in my opinion. Which renderers have no GL counterpart, besides MLAA? > An example of a software-only scaler is MLAA. But also in software > that scaler is incomplete. Should we drop it? (Or is someone > motivated to finish it)? I am motivated, but also short on time. Note that when finished, MLAA would be like the HQ scaler: we would compute slopes in MSX-resolution on the CPU, then upload that data into a texture and have it rendered at output resolution on the GPU. So it wouldn't remain a software-only scaler. Bye, Maarten |
From: Wouter V. <ver...@gm...> - 2019-02-24 08:53:08
|
These renderers should not be included in daily builds. These are not useful for users (and can only confuse them). I don't remember the last time i used these renderers for development, but then I also haven't worked on rendering stuff for many year. If it's easy to make these into optional (disabled by default) components then that's fine. But I also wouldn't mind dropping them. Maybe that's even better? We can always get them back from git. A few of our scaling algorithm exist in the software renderer (SDL) but not in openGL scalers (SDLGL-PP). The SDLGL-FBxx renderers could be a workaround for that. But OTOH nobody complained about the lack of these renderers. An example of a software-only scaler is MLAA. But also in software that scaler is incomplete. Should we drop it? (Or is someone motivated to finish it)? Wouter On Sun, Feb 24, 2019 at 8:52 AM Maarten ter Huurne <ma...@tr...> wrote: > Hi all, > > We currently have two renderers that are only built when the source tree > is not in "release mode": a flag we briefly set when tagging a release. > > The renderers are called SDLGL-FB16 and SDLGL-FB32. If I recall > correctly, these: > - render in MSX resolution in software (all our renderers do; doing this > on the GPU turned out to be very inefficient) > - scale in software (unlike SDLGL-PP) > - upload to video memory via OpenGL calls > > I'm wondering how to translate this to the Meson build. Currently it > works exactly like the non-Meson build, by looking at the release flag. > But conceptually it feels like this should be a component instead: these > renderers are an optional feature that can included or excluded from the > build. > > In the non-Meson build, components are implicit: a component is enabled, > unless: > - a required dependency is not found > - the component is disabled by the platform (via the LINK_MODE variable) > > So there is no way for the user to explicitly enable or disable > components. That's something we inherited from the autoconf way of > working, but over the years I've realized it's not a good approach: the > user should be able to control whether a component is enabled or not and > if the user explicitly enables it, it should be an error if the > component cannot be built. This is different from autoconf's approach, > which drops an optional component if a dependency is not available, even > if the user explicitly asked for that component. > > Fortunately, Meson has a different way of dealing with this. You can > define features and for each feature there is a flag that the user can > set to "enabled", "disabled" or "auto". The "auto" value is the autoconf > behavior: build the feature if possible, otherwise drop it. But if a > user selects "enabled", it is an error if the feature has missing > dependencies, such as a library that cannot be found. > > Since we have a better system for controlling features with Meson, > converting these renderers to a component controlled by a feature makes > sense. I think the feature should be specific to these renderers and no > longer tied to release mode, which also controls things like showing the > Git revision in the version number. > > What I would like to know: > - are these renderers still useful for testing? > - if so, do we want them enabled for developers only or also in daily > builds? > > Related to this is the question of what we want to do with software > scaling in general, but I'll compose a separate mail for that. > > Bye, > Maarten > > > > > > _______________________________________________ > openMSX-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openmsx-devel > |
From: Maarten t. H. <ma...@tr...> - 2019-02-24 07:52:41
|
Hi all, We currently have two renderers that are only built when the source tree is not in "release mode": a flag we briefly set when tagging a release. The renderers are called SDLGL-FB16 and SDLGL-FB32. If I recall correctly, these: - render in MSX resolution in software (all our renderers do; doing this on the GPU turned out to be very inefficient) - scale in software (unlike SDLGL-PP) - upload to video memory via OpenGL calls I'm wondering how to translate this to the Meson build. Currently it works exactly like the non-Meson build, by looking at the release flag. But conceptually it feels like this should be a component instead: these renderers are an optional feature that can included or excluded from the build. In the non-Meson build, components are implicit: a component is enabled, unless: - a required dependency is not found - the component is disabled by the platform (via the LINK_MODE variable) So there is no way for the user to explicitly enable or disable components. That's something we inherited from the autoconf way of working, but over the years I've realized it's not a good approach: the user should be able to control whether a component is enabled or not and if the user explicitly enables it, it should be an error if the component cannot be built. This is different from autoconf's approach, which drops an optional component if a dependency is not available, even if the user explicitly asked for that component. Fortunately, Meson has a different way of dealing with this. You can define features and for each feature there is a flag that the user can set to "enabled", "disabled" or "auto". The "auto" value is the autoconf behavior: build the feature if possible, otherwise drop it. But if a user selects "enabled", it is an error if the feature has missing dependencies, such as a library that cannot be found. Since we have a better system for controlling features with Meson, converting these renderers to a component controlled by a feature makes sense. I think the feature should be specific to these renderers and no longer tied to release mode, which also controls things like showing the Git revision in the version number. What I would like to know: - are these renderers still useful for testing? - if so, do we want them enabled for developers only or also in daily builds? Related to this is the question of what we want to do with software scaling in general, but I'll compose a separate mail for that. Bye, Maarten |
From: Maarten t. H. <ma...@tr...> - 2019-02-02 13:09:52
|
On zaterdag 2 februari 2019 12:53:41 CET Alex Wulms wrote: > I just received forwarded mail from Google Play. To wrap it up > shortly: if we publish new build/version of openMSX after Aug & 2019, > then the new version must support native 64-bit code in addition to > the native 32-bit code. > > I don't know what is the impact on the Android build of openMSX. The > forwarded mail contains links to documentation on how to become 64-bit > compliant. >From a quick look at the blog post I think that what we need to do is include both a 32-bit and 64-bit ARM .so in the APK. That should be fairly straightforward, as we already support 64-bit platforms and we have built multi-arch packages before when macOS was transitioning from PPC to x86. Of course theory and practice don't always align, but I don't see major roadblocks in the theory part. Note that we have yet to package openMSX with SDL2 for Android; that is probably more work, in particular because we have to implement touch controls in openMSX. Bye, Maarten |
From: Alex W. <ale...@sc...> - 2019-02-02 12:11:59
|
Dears, I just received forwarded mail from Google Play. To wrap it up shortly: if we publish new build/version of openMSX after Aug & 2019, then the new version must support native 64-bit code in addition to the native 32-bit code. I don't know what is the impact on the Android build of openMSX. The forwarded mail contains links to documentation on how to become 64-bit compliant. Kind regards, Alex -------- Doorgestuurd bericht -------- Onderwerp: Get your apps ready for the 64-bit requirement by August 1, 2019 Datum: Fri, 01 Feb 2019 04:27:57 -0800 Van: Google Play <nor...@go...> Antwoord-naar: Google Play <nor...@go...> Aan: goo...@xe... Google Play View as webpage » <https://www.google.com/appserve/mkt/vib/AHANi0bcnLGFatDCSy-38MJvI5f2Fj3wULyOGQKo7YXmn0IMBsl0o8tM9kvO_pb_UgX3aKi1mRouK_cMXr9O4QFuUCkQ6vn_7YG6XlphLugFvHAzDuYQZGLCFWwGgL8ZRJfh2MDrDhnFFu-6auYNhNe4WBxH98dKlinX86fg9GoAQvOfPRNgtiwZwlsPPFQn-D5x5_Cskg9upeEwg1zUI0XQekdzLVPjywUmjHS6ZT5rijtWbGovrg> Google Play <#> Developer update Hello Google Play Developer, In our latest blog post <https://www.google.com/appserve/mkt/p/AHANi0b9tcLZ7gjr75PardvD4ikWdiX17wc6VKtRKbbOiCT0fwGDHnx_l7oqYa7EhMzNOtvjls4ePAQkLo_S3qk-4xlobBlfz0Bkd9jKoOM9f2k3d4f950_JW-5OF-kaI-jiUiHqeulK1WAeRMirst2-eKtoFuFb0y0KRQ>, we detailed the requirement that apps using native code must provide a 64-bit version in addition to the 32-bit version by *August 1, 2019*. As you may know, 64-bit CPUs deliver faster, richer experiences, and we appreciate your support in ensuring our users have the best experience possible on the Android platform. *Action required* If you haven't yet, we encourage you to begin work for the 64-bit requirement as soon as possible. Many apps are written entirely in non-native code (e.g. the Java programming language or Kotlin) and will not need code changes. Please note that we are not making changes to our policy on 32-bit support. Google Play will continue to deliver apps with 32-bit native code to 32-bit devices. The requirement means that those apps will need to have a 64-bit version as well. To help you make the transition, we've prepared documentation <https://www.google.com/appserve/mkt/p/AHANi0aivS7cfxHsy4EmjkvAfxSZyi3QD8pF9o68qwGrqrkjd8DZ_lIurTmBEylNQdHP-8uHCjc8ALQLibOUsv1CB_1QQ_a5Kao6ZriJeL310NqW0cx7IaDhGQE0pP1_vQVTaw0zdpJowEGg_Q> on how to check whether your app already supports 64-bit and how to become 64-bit compliant. We're also providing a high-level timeline below. *Starting August 1, 2019:* * All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide. * Extension: Google Play will continue to accept 32-bit only updates to existing games that use Unity 5.6 or older until August 2021. *Starting August 1, 2021: * * Google Play will stop serving apps without 64-bit versions on 64-bit capable devices, meaning they will no longer be available in the Play Store on those devices. * This will include games built with Unity 5.6 or older. *The requirement does not apply to:* * APKs or app bundles explicitly targeting Wear OS or Android TV, which are form factors that do not currently support 64-bit code. * APKs or app bundles that Google Play won't install on Android 9 Pie or later (support for 64-bit does not need to extend to APKs that are only on Android 8 Oreo and below). If you have any questions, you can find additional information about adding 64-bit support here <https://www.google.com/appserve/mkt/p/AHANi0aivS7cfxHsy4EmjkvAfxSZyi3QD8pF9o68qwGrqrkjd8DZ_lIurTmBEylNQdHP-8uHCjc8ALQLibOUsv1CB_1QQ_a5Kao6ZriJeL310NqW0cx7IaDhGQE0pP1_vQVTaw0zdpJowEGg_Q>. The Google Play Team Conversation <https://www.google.com/appserve/mkt/p/AHANi0YGVbvBlf_ADg8YFWUi5u7GgMAKdQYjb0vUQTHdyFp3TPCUdSJoON4QQFazBMq1VBrsteqntAuJWU55iBspoo7B0L2NGqT443oVngPYE4Pan5lpiDpbY6xqRMnMDuRPzQZEwmCHoginJs6hX8syAEoU-wVJVD05YhNKmQdApRzeArOAHg9KLs8lM7U> Globe <https://www.google.com/appserve/mkt/p/AHANi0ZG9SNG68lYTrylm8K7J76EJl3TUBsmVATWlWYglUA1siEPu8B0-F0kBXt2tT3vBSQrmZQl0thU6ovskiIUiwvAWN9ZGy6biA1BOXHrg5YU5iscfP8J7fZh7oiBp58kweI3S1zBk5T6> © 2019 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA. <#> Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Play Developer account. |
From: Manuel B. <man...@gm...> - 2018-12-08 23:29:46
|
Hi all, There will soon be an announcement on our website: http://openmsx.org/ Currently waiting for all binaries to have been built. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ |
From: Alex W. <ale...@sc...> - 2018-01-21 22:20:42
|
Hi Maarten, hi all, To me the proposal of Maarten makes sense. It concerns obscure settings that probably nobody is aware about and with the proposal of Maarten the emulator still behaves sensible while the code will be simpler. That could be helpful when we eventually want to migrate to SDL2. Cheers, Alex Op 09-01-18 om 10:26 schreef Maarten ter Huurne: > Hi all, > > There are two keyboard-related settings of which I'm wondering if we > really need them. > > > The first is kbd_numkeypad_enter_key. It is documented like this: > > There is a subtle difference between numeric keypad of MSX computers and > of most host computers; the MSX computers have a '.' and a ',' on the > numeric keypad. On the other hand, the host computers have a '.' and an > 'ENTER' key on the keypad. > > In some respect it is logical that the 'ENTER' key on the host numeric > keypad is mapped to the 'normal' MSX 'ENTER' key. On the other hand, > that would make it impossible to enter the ',' on the MSX numeric > keypad. Therefore, the user can choose whether the host numeric keypad > ENTER key should be mapped to the MSX numeric keypad ',' (which is the > default) or to the main 'ENTER' key. > > usage: > set kbd_numkeypad_enter_key Shows the current value > set kbd_numkeypad_enter_key ENTER Maps the keypad enter key to the > main 'ENTER' key, instead of the comma key on the MSX keypad > > > I think there are two scenarios we should support: > 1. the user wants use the keypad like it functions on PC > 2. the user wants to enter the MSX numpad comma > > The first use case matches what "character" mapping mode is designed > for: you press a PC key, you want to see the same character appear on > the MSX regardless of where it is located on the MSX keyboard. So I > think that in character mode, the keypad Enter should always act as > Enter. > > If we'd implement that, then we could just have "key" mapping mode > always insert a comma, so we can support both scenarios without a > dedicated setting. > > > The second is kbd_numkeypad_always_enabled. It is documented like this: > > Some real MSX computers do not have a numeric keypad. openMSX will > ignore key presses on the host numeric keypad when emulating such an MSX > model. With this parameter, you can indicate that even on such MSX > models, presses on the host numeric keypad must be mapped to the MSX > numeric keypad. So, you can override accurate behaviour with it, which > is the reason that by default, this setting is set to 'off'. > > usage: > set kbd_numkeypad_always_enabled Shows the current setting > set kbd_numkeypad_always_enabled on Enables numeric keypad, even if the > emulated MSX does not have one > > > I think that in "character" mapping mode, openMSX should be trying to > get the right character typed, so it is strange that the PC numpad > doesn't do anything if the active MSX machine doesn't have a numpad. So > I propose to always process PC numpad keys in "character" mapping mode. > > We could even go a step further and map the PC numpad to the MSX primary > number and symbol keys when in "character" mapping mode. This means that > for example Konami games that are started by pressing 1-4 could be > starting using the PC numpad (they don't react to the MSX numpad). > > In "key" mapping mode, we could keep the current behavior: ignoring > numpad presses if no numpad exists. I don't think we really need a > setting for forcing a numpad on a machine that doesn't have one. The > openMSX keyboard code could be simplified a bit if we drop the setting. > We already drop the Yes/No keys unconditionally if they don't exist on > the keyboard of the active machine. > > > Since these are changes that affect the user experience, I didn't want > to make them without asking for feedback first. I doubt a lot of users > know about these settings though: I wasn't aware of them myself until I > started working on the keyboard code. > > Bye, > Maarten > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > openMSX-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openmsx-devel > |
From: Maarten t. H. <ma...@tr...> - 2018-01-09 09:26:14
|
Hi all, There are two keyboard-related settings of which I'm wondering if we really need them. The first is kbd_numkeypad_enter_key. It is documented like this: There is a subtle difference between numeric keypad of MSX computers and of most host computers; the MSX computers have a '.' and a ',' on the numeric keypad. On the other hand, the host computers have a '.' and an 'ENTER' key on the keypad. In some respect it is logical that the 'ENTER' key on the host numeric keypad is mapped to the 'normal' MSX 'ENTER' key. On the other hand, that would make it impossible to enter the ',' on the MSX numeric keypad. Therefore, the user can choose whether the host numeric keypad ENTER key should be mapped to the MSX numeric keypad ',' (which is the default) or to the main 'ENTER' key. usage: set kbd_numkeypad_enter_key Shows the current value set kbd_numkeypad_enter_key ENTER Maps the keypad enter key to the main 'ENTER' key, instead of the comma key on the MSX keypad I think there are two scenarios we should support: 1. the user wants use the keypad like it functions on PC 2. the user wants to enter the MSX numpad comma The first use case matches what "character" mapping mode is designed for: you press a PC key, you want to see the same character appear on the MSX regardless of where it is located on the MSX keyboard. So I think that in character mode, the keypad Enter should always act as Enter. If we'd implement that, then we could just have "key" mapping mode always insert a comma, so we can support both scenarios without a dedicated setting. The second is kbd_numkeypad_always_enabled. It is documented like this: Some real MSX computers do not have a numeric keypad. openMSX will ignore key presses on the host numeric keypad when emulating such an MSX model. With this parameter, you can indicate that even on such MSX models, presses on the host numeric keypad must be mapped to the MSX numeric keypad. So, you can override accurate behaviour with it, which is the reason that by default, this setting is set to 'off'. usage: set kbd_numkeypad_always_enabled Shows the current setting set kbd_numkeypad_always_enabled on Enables numeric keypad, even if the emulated MSX does not have one I think that in "character" mapping mode, openMSX should be trying to get the right character typed, so it is strange that the PC numpad doesn't do anything if the active MSX machine doesn't have a numpad. So I propose to always process PC numpad keys in "character" mapping mode. We could even go a step further and map the PC numpad to the MSX primary number and symbol keys when in "character" mapping mode. This means that for example Konami games that are started by pressing 1-4 could be starting using the PC numpad (they don't react to the MSX numpad). In "key" mapping mode, we could keep the current behavior: ignoring numpad presses if no numpad exists. I don't think we really need a setting for forcing a numpad on a machine that doesn't have one. The openMSX keyboard code could be simplified a bit if we drop the setting. We already drop the Yes/No keys unconditionally if they don't exist on the keyboard of the active machine. Since these are changes that affect the user experience, I didn't want to make them without asking for feedback first. I doubt a lot of users know about these settings though: I wasn't aware of them myself until I started working on the keyboard code. Bye, Maarten |
From: Wouter V. <ver...@gm...> - 2017-12-25 11:24:30
|
IMHO it's not a goal on itself to have all chip implementations separate from the MSXDevice classes. - For I8255 this separation turns out to be useful, because many devices reuse the I8255 chip. - For the V99x8 chip / VDP device separating them doesn't bring any real advantage. But there's also nothing that prevents separating them in the future. - For the sound devices we usually did separate the chip from the device. For many, but not all, it turned out that (sometimes years later) we could actually reuse the chip in a second device. But if we would have made the other choice, it wouldn't be difficult to separate them at that point. So I don't mind this inconsistency at all. I merely see it as an implementation detail that can be changed (in both directions) at any point. Wouter On Mon, Dec 25, 2017 at 1:37 AM, Maarten ter Huurne <ma...@tr...> wrote: > On Sunday, 24 December 2017 18:17:25 CET Wouter Vermaelen wrote: > > > I like the following option best. I think it's option b, or at least > > very close to it: > > - Copy the readIO, peekIo, writeIO() implementation to the I8255 class > > - (optionally) The existing readPortA() .. methods in I8255 can then > > become private. > > - The read/peek/writeIO methods in MSXPPI and SVIPPI remain but only > > delegate to I8255. > > I like this because it's simple and it also keeps the I8255 stuff and > > the MSXDevice stuff separated. > > Ah, so use the same method signatures as MSXDevice in I8255, without > actually inheriting from MSXDevice? I think that's an improvement over > the current situation, since it would reduce the duplicated code to one > line per method. > > It is inconsistent though to have the I8255 chip separated from > MSXDevice and have for example the VDP as an MSXDevice. Although if we > ever want to do something about that inconsistency for all devices, the > solution would be to separate chip from glue for all, so having I8255 as > a non-device class makes sense. > > > I don't think there's any impact on serialization. > > Agreed: the serialization would only be an issue if I8255 was made into > an MSXDevice. > > Bye, > Maarten > > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > openMSX-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openmsx-devel > |