![]() ![]() I took this even further and constructed the list of actual block colours and the block relationship table. Rearranging the data I was able to put together an Excel spreadsheet showing this relationship. I wanted to delve deeper and understand how the underlying relationships worked. I ended up generating a lookup table that gave me the result I was after but I was not content with just using this table. ![]() It was when I was building colour into the A2VideoStreamer that I wanted to know how the colours related to one another but I wasn't able to locate the information easily. Each of these could be discussed at length in their own right but I will not be covering them here today. There are references on the web that describe how DHGR came about, how its colours are made up, how DHGR can be programmed and and how the data is stored. This blog entry is about trying to build a colour relationship model, to show how that can be used to improve the areas where DHGR is used in design and to show off what could have been. Most people will attribute the Apple II with High Resolution Graphics (HGR) and when you compare it to its competitors at the time I believe colour DHGR did not get the opportunity to be represented as much as it could have been. By the time computers with colour monitors were affordable, colour graphics had surpassed DHGR type graphics. Even after 1986 when the the IIGS was released, my school, myself and many people that I know were still using the IIe with a monochrome monitor. The monochrome resolution is 560x192 but when using colour this resolution falls back to roughly 140x192 since a block of 4 bits is used to represent 16 different colours (15 colours on the IIe because the two greys produce the same colour). ![]() DHGR mode is not available on the earlier models but it is available on the IIe (with a RevB motherboard and an 80column card), the IIc and the IIGS. Maybe propose a scaling option based on double or float calculations ( it's no more pixel perfect, but it will be far better looking with 1080p anyway ).These title pictures are photos taken of a composite monitor attached to a standard Apple IIe with an 80 column card.ĭouble High Resolution Graphics (DHRG) is the highest resolution of graphics that is natively supported by the 8bit Apple II line of computers.Recompute the best scaling before switching to fullscreen ( or you stay with ratio x4 with 1080p - I should at least be 5 ).I keep my suggestion for a -strech command line argument, which is probably the best solution ( or as an option ).If you set a resolution with these arguments, you still have the same problems, but it's just worse because you loose the original aspect ratio, so the Apple2 screen is always deformed & stretched. It's actually 2, so you loose about 168 pixels top & 168 pixels bottom -> You loose 46% of the height !!!!! Perfect vertical scale for 720p fullscreen should be 3.75. It's actually 4, so you loose about 156 pixels top & 156 pixels bottom -> You loose 28,8 % of the total screen height (calculations based on heights). Perfect vertical scale for 1080p fullscreen should be 5.625. It's related to the fact that the scaling is based on integers & that switching to fullscreen does not recompute that factor. When switching to fullscreen, you still use the same initial computed size, but final proportions look very different.Īs they both are 16:9 resolutions, they should look about the same, but it's not. When set to fullscreen with integers & 1920x1080 you should resolve to 5 ( 5x192 = 960 ). If you have a desktop 16:9 resolution of 1920x1080 the main window size is 1181x807. If you have a desktop 16:9 resolution of 1280x720 the main window size is 621x423. ![]() If you don't start with -fs-height/width and switch to fullscreen with -f or manually : Resolution & ratios are different problems. It's working well without any argument, but it may not be a good idea. Perhaps if the user doesn't specify a command line for -fs-width or -fs-height, then just use the old method (ie. Since xscale = yscale (for with or without VidHD) then I didn't notice, since it's the same behaviour as before. I think I understand - it's because I now allow separate x & y (integer) scaling: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |