Re: X11 video scaling
On 27 July 2012 20:41, Jeffrey Lee m...@phlamethrower.co.uk wrote: On Fri, 27 Jul 2012, Andrew Flegg wrote: Is there something I've missed which'd allow video scaling (say 2x) for modes 640x480. For the X11 port, the place to start looking is the SDD_Name(Host_ChangeMode)() function, which is actually implemented in two places - X/pseudo.c for pseudocolour displays and X/true.c for truecolour displays. Attached is the start of the patch - if the screen is smaller than 640px wide, the scale factors are increased (though with a limit due to the maximum horizontal scaling being 2x because of the fast render routines previously discussed). I've tested this in the desktop; BASIC and games like Cannon Fodder (rectangular pixels, I think); Lemmings; Stib; Hopper; Chuckie Egg and a few others. However, it looks like I didn't fix the mouse pointer image code to take into account the scale factors, so you'll be wanting to change that. This version of the patch doesn't contain that code (given games tend not to use the hardware mouse pointer), however I'll look into it. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ small-scaling.patch Description: Binary data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/-- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On 27 July 2012 20:41, Jeffrey Lee m...@phlamethrower.co.uk wrote:
On Fri, 27 Jul 2012, Andrew Flegg wrote:
Is there something I've missed which'd allow video scaling (say 2x)
for modes 640x480.
For the X11 port, the place to start looking is the
SDD_Name(Host_ChangeMode)() function, which is actually implemented in two
places - X/pseudo.c for pseudocolour displays and X/true.c for truecolour
displays. As you can see there's code in there to set HD.XScale and
HD.YScale to take into account rectangular pixel modes. So adding support
for 2x, 3x, 4x, etc. upscaling is just a case of changing HD.XScale,
HD.YScale, width, and height to the appropriate values.
Thanks for the pointer. However, I'm getting a weird effect when
XScale 2. Effectively, it acts like XScale = 1 (although YScale
works).
To reproduce:
1) In true.c's SDD_Name(Host_ChangeMode) add the following after HD.XScale
and HD.YScale are initialised to 1:
int origWidth = width, origHeight = height;
2) Add the following above the calculation of HD.Width and HD.Height:
while (width 800) {
HD.XScale *= 2;
HD.YScale * =2;
height = origHeight * HD.YScale;
width = origWidth * HD.XScale;
}
3) Make run `arcem'
In the default mode of 28, this works (although 2x zoom on 640px is a
bit too large for my tastes). Press F12 and enter `wimpmode 13'.
At this point, the vertical scaling is as you'd expect, but despite
HD.YScale being set to 3, and the window being set to the correct
size, the screen display within the window only takes up a third of
the width.
Setting it to a power of 2 doesn't help either.
What happens to 'HD' after its been initialised? What actually does
the pixel blatting and how could this be getting confused with a 2
XScale, but not a 2 YScale?
Cheers,
Andrew
--
Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--
arcem-devel mailing list
arcem-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On 29 July 2012 20:09, Andrew Flegg and...@bleb.org wrote: What happens to 'HD' after its been initialised? What actually does the pixel blatting and how could this be getting confused with a 2 XScale, but not a 2 YScale? Ah, it seems that SDD_Name(RowFunc) dispatches to an explicit set of functions which only support 1X and 2X. Hmm. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On 29 July 2012 20:18, Andrew Flegg and...@bleb.org wrote: Ah, it seems that SDD_Name(RowFunc) dispatches to an explicit set of functions which only support 1X and 2X. Hmm. These 16 functions (1bpp, 2bpp, 4bpp, 8bpp @ 1x. 2x with flags and without flags) are all *very* similar and look like they should be very abstractable. However, it's not something I've got time to do right now - and a pretty boring task at the best of times ;-) -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On Sun, 29 Jul 2012, Andrew Flegg wrote: On 29 July 2012 20:09, Andrew Flegg and...@bleb.org wrote: What happens to 'HD' after its been initialised? What actually does the pixel blatting and how could this be getting confused with a 2 XScale, but not a 2 YScale? Ah, it seems that SDD_Name(RowFunc) dispatches to an explicit set of functions which only support 1X and 2X. Hmm. Yes, I guess I forgot about that! Are you planning on using 2x horizontal scaling? I can add an extra set of functions to deal with arbitrary scale factors. Or you can try it yourself, if you're feeling brave enough. Cheers, - Jeffrey -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On 29 July 2012 20:31, Jeffrey Lee m...@phlamethrower.co.uk wrote: On Sun, 29 Jul 2012, Andrew Flegg wrote: Ah, it seems that SDD_Name(RowFunc) dispatches to an explicit set of functions which only support 1X and 2X. Hmm. Yes, I guess I forgot about that! :-) Are you planning on using 2x horizontal scaling? I can add an extra set of functions to deal with arbitrary scale factors. Or you can try it yourself, if you're feeling brave enough. 320x256 is common for games, but blowing these up by 3x to 960x768 seems sensible (on my setup at least). Adding another set for 3x would be the easiest option, but adding support for arbitrary scaling factors would be more flexible and also *reduce* the amount of code (when the different variants of BPP flags are taken into account). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On Sun, 29 Jul 2012, Andrew Flegg wrote: On 29 July 2012 20:18, Andrew Flegg and...@bleb.org wrote: Ah, it seems that SDD_Name(RowFunc) dispatches to an explicit set of functions which only support 1X and 2X. Hmm. These 16 functions (1bpp, 2bpp, 4bpp, 8bpp @ 1x. 2x with flags and without flags) are all *very* similar and look like they should be very abstractable. However, it's not something I've got time to do right now - and a pretty boring task at the best of times ;-) Abstractable, yes. Abstractable without impacting performance? Doubtful. Remember that I fought long and hard to get ArcEm to run at ARM2 speeds on an Iyonix, so I don't really want us to start doing things that will harm performance unless we've got a good reason! Of course it might be possible to use more macro trickery to reduce the amount of coude, but whether that results in the code being more readable is open to question. Cheers, - Jeffrey -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On 29 July 2012 20:41, Jeffrey Lee m...@phlamethrower.co.uk wrote: Abstractable, yes. Abstractable without impacting performance? Doubtful. Remember that I fought long and hard to get ArcEm to run at ARM2 speeds on an Iyonix, so I don't really want us to start doing things that will harm performance unless we've got a good reason! Fair point, the first pass I'd do is to have a single method which always calls through to Write_Pixels (which might then have special casing when n = 1). Is the additional method calling overhead the concern? Of course, X/true.c isn't used on the Iyonix (i.e. RISC OS port) is it? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On Sun, 29 Jul 2012, Andrew Flegg wrote: On 29 July 2012 20:41, Jeffrey Lee m...@phlamethrower.co.uk wrote: Abstractable, yes. Abstractable without impacting performance? Doubtful. Remember that I fought long and hard to get ArcEm to run at ARM2 speeds on an Iyonix, so I don't really want us to start doing things that will harm performance unless we've got a good reason! Fair point, the first pass I'd do is to have a single method which always calls through to Write_Pixels (which might then have special casing when n = 1). Is the additional method calling overhead the concern? Anything that could conceivably make things slower is a concern ;) If you were always calling Write_Pixels, and the number of pixels isn't known at compile time, then Write_Pixels is always going to force the CPU to either branch or loop, which will obviously be slower than how things are now, where the compile can optimise any loops out of Write_Pixels. Of course I haven't actually tried doing the above, so I've got no idea whether it'll be significantly slower or not. Of course, X/true.c isn't used on the Iyonix (i.e. RISC OS port) is it? X/true.c isn't, but arch/stddisplaydev.c is (which as you've spotted contains the guts of the display code). Cheers, - Jeffrey -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On 29 July 2012 20:50, Ian Jeffray i...@jeffray.co.uk wrote: On 29/07/2012 20:34, Andrew Flegg wrote: 320x256 is common for games, but blowing these up by 3x to 960x768 seems sensible (on my setup at least). Adding another set for 3x would be the easiest option, but adding support for arbitrary scaling factors would be more flexible and also *reduce* the amount of code (when the different variants of BPP flags are taken into account). So long as we don't lose performance... lots of separately optimised functions are good for performance. And they're not /quite/ as similar as you may think at first glance. I admit I didn't diff all 16 ;-) But the differences between RowFunc8bpp2X and RowFunc8bpp1X seemed to be: * VIDEO_STAT(DisplayRedrawForced) - 'flags ROWFUNC_FORCE' vs. 'force' (is that a mistake?) * Shifting of Available (2 vs. 3) - is that (4-HD.XScale)? * Host_WritePixels vs. Host_WritePixel - could use a macro to avoid additional function call overhead. There was more difference between RowFunc8bpp2X and RowFunc4bpp2X, but mostly power of two shifting; although the differences between the palette and the cleverness around Shift may be harder to commonise. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On 29 July 2012 20:58, Jeffrey Lee m...@phlamethrower.co.uk wrote: On Sun, 29 Jul 2012, Andrew Flegg wrote: Anything that could conceivably make things slower is a concern ;) Fair enough. My day job makes me think that anything that makes such a dent on maintainability is also a concern - but I don't write emulators where the priorities are different :-) [Fasterer is definitely betterer, agreed!] X/true.c isn't, but arch/stddisplaydev.c is (which as you've spotted contains the guts of the display code). Oh yeah. I'll blame trying to get familiar with a new codebase, rather than a complete failure of memory or reading ability ;-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
On Sun, 29 Jul 2012, Andrew Flegg wrote: On 29 July 2012 20:50, Ian Jeffray i...@jeffray.co.uk wrote: So long as we don't lose performance... lots of separately optimised functions are good for performance. And they're not /quite/ as similar as you may think at first glance. I admit I didn't diff all 16 ;-) But the differences between RowFunc8bpp2X and RowFunc8bpp1X seemed to be: * VIDEO_STAT(DisplayRedrawForced) - 'flags ROWFUNC_FORCE' vs. 'force' (is that a mistake?) Yes, that's a mistake. I guess I didn't try compiling with video stats enabled after I swapped 'force' for a flags word. * Shifting of Available (2 vs. 3) - is that (4-HD.XScale)? 'Availalable' is the number of available source bits, so Available3 would be the number of source pixels. So it's really (Available3)*HD.XScale, which can be hand-optimised to (Available2) for the 2x case (since it's guaranteed the low three bits of 'Available' won't be set) (When writing the code I found it easier to count some of the values in bits rather than pixels - although I can't quite remember why!) Cheers, - Jeffrey -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: X11 video scaling
Hi Andrew, On Fri, 27 Jul 2012, Andrew Flegg wrote: Hi, Is there something I've missed which'd allow video scaling (say 2x) for modes 640x480. It looks like the other ports have something like it, so are there any pointers for where to start hacking on it? Presumably, the scaling factor and size at which to do scaling should be configurable. Perhaps as a minimum size option? Anything smaller than that gets (integer) scaled to get as close as possible? For the X11 port, the place to start looking is the SDD_Name(Host_ChangeMode)() function, which is actually implemented in two places - X/pseudo.c for pseudocolour displays and X/true.c for truecolour displays. As you can see there's code in there to set HD.XScale and HD.YScale to take into account rectangular pixel modes. So adding support for 2x, 3x, 4x, etc. upscaling is just a case of changing HD.XScale, HD.YScale, width, and height to the appropriate values. However, it looks like I didn't fix the mouse pointer image code to take into account the scale factors, so you'll be wanting to change that. It looks like this will involve: * Changing the code in DisplayDev_Init() (in X/DisplayDev.c) that deals with setting up PD.CursorPane, PD.CursorImageData, PD.CursorImage, PD.ShapePixmapData, and PD.shape_mask to allow for cursors wider than 32 pixels. Adding a global variable or #define for the max cursor width would probably make sense! (e.g. to X/platform.h) * It looks like there's also code in Resize_Window() that deals with setting up the above variables, that will need modifying too. * Then there's RefreshMouse() (in both X/true.c and X/pseudo.c) which deals with filling the cursor image with data. The nested for() loops it uses to fill the image are a bit nasty, so I'll leave it to you to decide how best to tidy them up! (Perhaps that's the reason why I didn't update the code...) * There's also an XCreatePixmapFromBitmapData() call in RefreshMouse() that will need to take into account the wider cursor width. * Finally there's the XPutImage() call at the end of SDD_Name(Host_PollDisplay)() (in both X/true.c and X/pseudo.c) which will need updating for the wider cursor width. Good luck! - Jeffrey -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
