To be quite specific in what I'm wanting to do...
I have a scrollable map on a canvas. I have zoom in/out capabilities. I want to place a cross hair/bullseye on top of the map so I know where I am going to be zooming in/out with high accuracy. I realize I could be more flexible and do it by locating the mouse pointer position and just have it zoom in/out based on where the mouse is at but I think given the magnitude of the project and the way it keeps evolving I better plan otherwise.
I'm thinking I would have to have two canvases on the screen to pull off what I'm wanting to do. That shouldn't be a problem. The problem...is it possible to make the top canvas trans????, is that parent or lucent...aka see-thru(I can never remember which is which, LOL:)) while still being able to see the cross hairs placed on the center of the top canvas. I don't think it could be done with only one canvas but I might be wrong.
Yes, this is a bit of a tricky question.
No, it is not possible to have a transparent canvas.
If all you need is a crosshair, just draw one on the canvas. You can hide it temporarily while you zoom so that it doesn't get zoomed along with everything else.
What am I trying to ask is not highlighting the whole background when I am currently on that line.
What I want to ask is if I am making comments and so I have seen a file few weeks back that only a few lines' background is totally different let's say red so when we are scrolling up and down it'll be lots easier to see OH! This is one of the sections.
I have been making huge comments like /****/ with lots of * in order to separate each sections.
The picture below where the red part is something I am looking for.
A huge highlight for few rows which makes it easier to divide sections if needed to.
Having read the SVG2 draft, I am slightly disappointed to learn that there will be no new line caps than the standard 3. The new arc line join is brilliant however, but not what this question is about (I just wanted to mention that).
I had been hoping for a cap that ends in a triangle. But given my use case, that might not be ideal either.
As far as I can gather, Adobe Illustrator - which I do not use myself - allows the width of a stroke to be variable. This is useful when drawing from a drawing tablet, to highlight the pressure of the lines. It's true, this functionality exists in many bitmap drawing programs, but is there a way to achieve this effect in SVG, without having to draw multiple lines?
The idea is that each node should have a width, and the lines should then 'smoothly' scale the width between each node that had a different width.
Is this possible? And if not, could it be considered?
P.S. I should point out, that this is more a thought experiment and an idea than something that hinders my process. More of a nice to have than need to have.
While this may not be a true answer (SVG standard wise at least), it turns out that in the current trunk version of Inkscape, this feature called PowerStroke already exists. There are some screenshots of PowerStroke.
This should satisfy my quest for the time being.
It turns out - as well - that the arc line joins was actually suggested by Inkscape as well, they are just called extrapolate in Inkscape.
I saw an infographic online that I wanted to use as a challenge to learn d3.js. The original infographic is here:
http://www.shah3d.com/wp-content/uploads/2012/11/IG-WWF-Dehahs.png
I've made a start here:
http://www.tips-for-excel.com/d3test/arc/arc%20test.html
You'll notice that the original has nice lines that link an arc from the bottom with an arc along the top. So far I can only think of painfully placing lots of circles to achieve this effect, hence the odd red circle currently in my visual. What would people's best methods be to replicate the original graphic? Which element would make this task easier? Arcs? Lines? I imagine I'll have to manipulate my data so that the lines go where they're meant to.
Happy to give more info if needed and thanks for taking time to read this.
There are a few existing diagrams to work off of from d3's galleries:
http://bl.ocks.org/4062006
http://bost.ocks.org/mike/uberdata/
Both use the length of the chord as the width of the stroke (initially), but you can tinker with that, for sure.
Graphically, you could use arcs, or full circles with a clip around it. As to the 'best' way to do it, that may come out of 'requirements' of how your graphic needs to behave (animation, relative arc placement, etc).
Personally, I'd go with path arcs.
I have heard that old arcade side scrolling games used a specific programming hack to enable performant side scrolling.
I understand that years ago the machines weren't powerful enough to repaint the whole screen every frame as it's done nowadays. There are techniques, such as dirty rectangles, which allow to minimise the screen area needed to repaint when the background is stationary and only the sprites move.
The above approach only works when the background doesn't change (and hence most of the screen pixels remain stationary).
Vertical scrolling games, like old school shoot'em ups, have the thing a bit more difficult with the background changing every frame due to the scroll. However, one could take advantage of the way pixels are fed to the display (line-by-line). I imagine that one could use a bigger buffer and shift the data pointer some lines "down" every frame, so that it will be redrawn starting from another position, thus giving the impression of a smooth scroll. Still only sprites (and a bit of the background at the edge of the screen) would need to be redrawn, which is a serious optimisation.
However, for side scrolling games, the thing is not that simple and obvious. Still, I'm aware that somebody, somewhere in the past, has though of an optimisation which (with some limitations) allowed the old machines to scroll the background horizontally without redrawing it every frame.
IIRC it was used in many old games, mostly 80's beat'em ups, as well as in demoscene productions
Can you describe this technique and name its author?
I have written games for the good old C64 doing exactly this. And there are basically two things to be aware of:
These games were NOT using bitmapped graphics, but instead used "remapped" character fonts, which means that chunks of 8x8 pixels were actually hurdled around as just one byte.
The next thing to note is that there was hardware support for displacing the whole screen seven pixels. Note that this didn't in any way affect any graphics - it just made everything sent to the TV a little bit displaced.
So 2) made it possible to really smooth scroll 7 pixels away. Then you moved every character around - which for a full screen was exactly 1000 bytes, which the computer could cope with, while at the same time you moved the scrolling register back 7 pixels. 8 - 7 = 1 means that it looked like you scrolled yet another single pixel... and then it just continued that way. So 1) and 2) combined made the illusion of true smooth scrolling!
After that a third thing came into play: raster interrupts. This means that the CPU gets an interrupt when the TV/monitor was about to begin drawing a scan line at a specified location. That technique made it possible to create split screen so that you weren't required to scroll the entire screen as opposed to my first description.
And to be even more into details: even if you didn't want a split screen, the raster interrupt was very important anyway: because it was just as important then as it is today (but today the framework hides this from you) to update the screen at the right time. Modifying the "scroll register" when the TV/monitor was updating anywhere on the visible area would cause an effect called "tearing" - where you clearly notice the two parts of the screen are one pixel off sync with each other.
What more is there to say? Well, the technique with remapped character sets made it possible to do some animations very easily. For example conveyors and cog wheels and stuff could be animated by constantly changing the appearance of the "characters" representing them on screen. So a conveyor spanning the entire screen width could look as it was spinning everywhere by just changing a single byte in the character map.
I did something similar way back in the 90s, using two different approaches.
The first one involved "windowing," which was supported by the VESA SVGA standard. Some cards implemented it correctly. Basically, if you had a frame buffer/video RAM larger than the displayable area, you could draw a large bitmap and give the system coordinates for a window within that area that you wanted to display. By changing those coordinates, you could scroll around without having to re-fill the frame buffer.
The other method relied on manipulating the BLT method used to get a completed frame into the frame buffer. Blitting a page to the frame buffer that was the same size as the screen is easy and efficient.
I found this old 286 assembler code (on a functioning 17 year old floppy!) that copied a 64000 byte (320x200) screen from an off-screen page to the video buffer:
Procedure flip; assembler;
{ This copies the entire screen at "source" to destination }
asm
push ds
mov ax, [Dest]
mov es, ax
mov ax, [Source]
mov ds, ax
xor si, si
xor di, di
mov cx, 32000
rep movsw
pop ds
end;
The rep movsw moved CX words (where a word is two bytes in this case). This was very efficient since it's basically a single instruction that tells the CPU to move the whole thing as quickly as possible.
However, if you had a larger buffer (say, 1024*200 for a side scroller), you could just as easily use a nested loop, and copy a single row of pixels per loop. In the 1024-pixel wide buffer, for instance, you could copy bytes:
start count
0+left 320
1024+left 320
...
255*1024+left 320
where left is the x coordinate within the large background image that you want to start at (left side of the screen).
Of course, in 16-bit mode, some magic and manipulation of segment pointers (ES, DS) was required to get a buffer larger than 64KB (in reality, multiple adjacent 64k buffers), but it worked pretty well.
There were probably better solutions to this problem (and definitely better ones to use today), but it worked for me.
Arcade games frequently featured customized video chips or discrete logic to allow scrolling without the CPU having to do (much) work. The approach would be similar to what danbystrom was describing on the C-64.
Basically the graphics hardware took care of fine scrolling characters (or tiles) and the CPU then handled replacing all tiles once the scrolling registers have reached their limit. I am currently looking at the Irem m-52 board which deals with multiple scrolling backgrounds in hardware. Schematics can be found online.
For right scrolling on the Commodore Amiga we used the Copper to right-shift the screen up to 16 pixels. When the screen had shifted we added 2 bytes to the start address of the screen buffer while on the right side we used the Blitter to copy graphics from the main memory to the screen buffer. We would set the screen buffer slightly larger than the screen view so that we could copy the graphics without you seeing a flickering effect from the copying on the right side of the viewport.