English Amiga Board Is it possible to combine 2 different sized images with the blitter?
 Register >> Amiga FAQ/Wiki << Rules & Help Members List  /  Moderators List Search Today's Posts Mark Forums Read

 View Poll Results: Can you end up with continuous 16 pixel wide output for this problem? Yes, I believe it can be done! 3 60.00% No, I don't think it can! 2 40.00% Voters: 5. You may not vote on this poll

 21 February 2012, 00:31 #1 Codetapper Moderator     Join Date: May 2001 Location: Auckland / New Zealand Age: 38 Posts: 2,461 Is it possible to combine 2 different sized images with the blitter? I have 2 images, one is a large bitmap, let's say it's a standard Amiga screen of 320x200. I want to extract a 16 pixel wide rectangle from it starting at any X position. For the sake of the example, let's say I want to grab 16 pixels from 45 pixels in from the left. Call this source A and is the black rectangle in the pic. The white rectange A represents the word aligned version (2 words needed to be fetched to contain the valid data). Then I want to combine it with another one bitplane image which is only 16 pixels wide, and always word aligned. The data is continuous, so the 1st word is the top 16 pixels, the very next word is the word underneath. Call this source B. Note that B is not part of the source A image, it's just drawn there so you can see it. The optimal output of this blit operation would be a single 16 pixel wide image, combining the 2 sources (I've used an AND operation in this case). In the example the final data I want is the green D image and again continous in memory. Is it possible? Because source A is shifted, to extract the data from 45 pixels indented you would assume that you require a blit width of 2 words and set the bltapt to the white rectangle address. Then source B would need a modulo of -2 since it's 1 word wide but we're having to process 2 words. And the destination D you would also expect to have a modulo of -2. Now for the problem! This seems to be a trivial problem IF you are happy to have the destination end up as a 32 pixel wide masked image. However I would like a 16 pixel wide image! If you operate the blitter in ascending mode, use a right shift of 16 - 5 = 11 for source A with a mask of \$0000ffff, and have source B pointing to 1 word before the B data with a modulo of -2 and using a minterm D=AB, I believe it will process the first line correctly but when it comes to the second line, it'll end up overwriting the first lines data as the 1st word is junk (masked away and shifted) and the 2nd word is valid. Then the modulo of -2 will kick in, and the next line's junk 1st word will end up overwriting the valid word that it's just processed. Operating the blitter in descending mode will surely do exactly the same but in reverse, the blitter as it operates will end up destroying the valid data just above it in memory. So my question is, can you actually do this operation to end up with a continuous 16 pixel width destination, or do you have to put up with an extraneous word between each line? Attached Thumbnails
 21 February 2012, 00:52 #2 Lonewolf10 AMOS Extensions Developer     Join Date: Jun 2007 Location: near Cambridge, UK Age: 33 Posts: 925 I'm no expert, so take this with a pinch of salt, but I think you'd have to do it as a 32 pixel wide image onto another bit of memory (offscreen). Then take your 16 pixel wide image from that and copy it onto your intended destination screen. I'm interested to see what the others think... Regards, Lonewolf10 __________________ My stuff on Aminet is here All Square by Digital Dalmatian is here
 21 February 2012, 01:28 #3 h0ffman Registered User   Join Date: Aug 2008 Location: Salisbury Posts: 349 You're modulo values are all out. If the screen width is 320 (40 bytes) and the blit with 2 words, then the modulo on all channels would be 40-4 = 36 Don't know if that helps.
21 February 2012, 01:47   #4
Codetapper
Moderator

Join Date: May 2001
Location: Auckland / New Zealand
Age: 38
Posts: 2,461
Quote:
 Originally Posted by Lonewolf10 I'm no expert, so take this with a pinch of salt, but I think you'd have to do it as a 32 pixel wide image onto another bit of memory (offscreen). Then take your 16 pixel wide image from that and copy it onto your intended destination screen. I'm interested to see what the others think...
Indeed. Unless there's some magic way possibly using another blitter channel or something.

Quote:
 Originally Posted by h0ffman You're modulo values are all out. If the screen width is 320 (40 bytes) and the blit with 2 words, then the modulo on all channels would be 40-4 = 36 Don't know if that helps.
I didn't specify the A channel modulo - I left it out as I thought it was obvious. Indeed it would be 36 in this case. The modulos for B and D channels however would be -2 not 36 because I am not blitting to the screen - just to a 16 pixel wide buffer.

Just to add to the question, I can get around the problem by outputting to the 32 pixel buffer and using that, but it's an interesting exercise to see if it can be done. The RKMs mention Amiga fonts being stored in a packed format and extracted using masks with the blitter so perhaps there's a way to do it without using a wider buffer!

 29 February 2012, 14:36 #6 Photon Oldskool Demo Coder     Join Date: Nov 2004 Location: Hult / Sweden Age: 41 Posts: 3,674 Regarding the original topic title: no. The blitter window is the same for all sources and destination in that a line in each is the same number of words. Some things may seem like changing the size, such as tripling the height blitting a 3 bitplane interleaved bob. Where the destination modulo is 0 you can also do some tricks. Here the only thing that requires a line width of 2 words is that the 16-pixel sliver A is non-word aligned in most cases. You will never get the bits that are sticking into the next word with just a 1-word wide blit, simple as that. You can remove the requirement with a coSTly trick, keeping 16 differently scrolled backgrounds in memory. With masking, you can make the blit affect a window up to 2 words less wide. The 2 word width and desired 1 word wide destination graphic makes the blitter pipelining come into play, and usually setting descending mode fixes that fine if source and destination overlaps for the final OR ("affect") operation. But in this case where destination and destination overlaps the destination must be cleared to start with, then first/last word mask used to only affect the last or first word of each line. On Amiga, whenever a coder is given the choice of wasting cycles or memory, the answer is always memory. Make it two words wide and skip all the trickery, and check if it happens to be aligned to save half the cycles in 1/16 of the cases. Voted yes as it can be done, if the destination is cleared first. I can't see any replacement of pixels in the destination not causing pipeline trashing in asc/desc mode. __________________ Henrik. Programs Amiga demos, iPhone apps, websites, etc. A1000/512k - A500 2.0/040@28/4M/.5M slowmem/8M/SCSI/CF - A600 portable II 3.1/ACA630/WiFi/CF - 'A1700' 3.1/68060@80/64M/IDE-Fix Express/CF - etc."The difference between PC and Amiga is that 10yo PCs are worth \$0. 20yo Amigas are worth a lot, and Amigas that are only 15yo cost a fortune!" If you like Portal 2, try my >> single player and cooperation maps <<

 Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home News » Main     Amiga scene     Retrogaming General Discussion     Nostalgia & memories     New to Emulation or Amiga scene         Member Introductions     support.WinUAE     support.WinFellow     support.OtherUAE     support.FS-UAE     support.Hardware         Hardware mods         Hardware pics     support.Games     support.Demos     support.Apps     support.Amiga Forever     support.Other » Requests     request.UAE Wishlist     request.Old Rare Games     request.Demos     request.Apps     request.Modules     request.Music     request.Other     Looking for a game name ?     Games images which need to be WHDified » abime.net - Hall Of Light     HOL news     HOL suggestions and feedback     HOL data problems     HOL contributions » abime.net - Amiga Magazine Rack     AMR news     AMR suggestions and feedback     AMR data problems     AMR contributions » abime.net - Home Projects     project.Amiga Lore     project.EAB     project.IRC     project.Mods Jukebox     project.Wiki » abime.net - Hosted Projects     project.aGTW     project.APoV     project.ClassicWB     project.Jambo!     project.Green Amiga Alien GUIDES     project.Sprites     project.WinUAE - Kaillera » Other Projects     project.Amiga Demo DVD     project.Amiga Game Factory     project.CARE     project.EAB File Server     project.Game Cover Art         GCA.Feedback and Suggestions         GCA.Work in Progress         GCA.Cover Requests         GCA.Usefull Programs         GCA.Helpdesk     project.KGLoad     project.MAGE     project.Missing Full Shareware Games     project.SPS (was CAPS)     project.TOSEC (amiga only)     project.WHDLoad         project.Killergorilla's WHD packs » Misc     Amiga websites reviews     MarketPlace         Swapshop     EAB's competition » Coders     Coders. General         Coders. Releases         Coders. Tutorials     Coders. Asm / Hardware     Coders. System         Coders. Scripting         Coders. Nextgen     Coders. Language         Coders. C/C++         Coders. AMOS » Off Topic     OT - General     OT - Gaming     OT - Technical     OT - Entertainment     OT - Sports

 Similar Threads Thread Thread Starter Forum Replies Last Post Lonewolf10 Coders. Tutorials 7 13 September 2011 14:30 h0ffman Coders. General 13 05 April 2011 04:23 Photon support.Demos 14 01 December 2006 11:07 Peanutuk MarketPlace 2 18 February 2004 11:33

All times are GMT +2. The time now is 03:09.

-->