[Q]Just draw an ellipse with a rectangle 1 pixel wide and 1 pixel tall[\Q]
That is an extremely stupid way to draw a point...
DrawBezier, DrawCurve, DrawEllipse, &al all have their uses, and in those cases are much better than a legion of psets, but a language without pset??? Where the coders stoned?
Wouldn't DrawLine be less inefficient than DrawEllipse?
[Q]Just draw an ellipse with a rectangle 1 pixel wide and 1 pixel tall[\Q]
That is an extremely stupid way to draw a point...
DrawBezier, DrawCurve, DrawEllipse, &al all have their uses, and in those cases are much better than a legion of psets, but a language without pset??? Where the coders stoned?
Wouldn't DrawLine be less inefficient than DrawEllipse?
There are a few ways to draw a point. Some more effective than others. VB.Net's GDI+ is a vast improvement over classic VB. Get over it
The line is better than the ellipse at these sizes...
Code:
Private Sub Form5_Paint(ByVal sender As Object, ByVal e As System.Windows.Forms.PaintEventArgs) Handles Me.Paint
e.Graphics.DrawLine(New Pen(Color.Black, 2), 50, 150, 51, 150) '2 pixel dot
e.Graphics.FillEllipse(Brushes.Black, New Rectangle(50, 160, 5, 5)) '5 pixel dot
End Sub
Why would you want to draw a point? If you are drawing a single pixel, the odds are that it would barely be visible on most systems. If you want to draw something else, then draw what you want. There are a few built in things, such as squares and ellipses. Both of those are dots if they are small enough. You could also add a 'dot' of any particular shape you want and draw it as an image.
Basically, what is a dot? Drawing a single pixel has very little value anymore. Most people want to draw something scaled. If you were used to setting a single pixel, you can still do it, it's just that you can barely see it, so it generally isn't worth drawing. If you were drawing a 'dot' that was larger than one pixel at any point in the past, then what you were drawing wasn't a dot, it was something else. The way you were doing it might have hidden what was actually happening, but if it wasn't setting a single pixel, then it was drawing some kind of shape.
You mentioned hextiles. That makes me think that the image you are drawing might be large (like a game map). If that's the case, performance may not be all that great using GDI. I've had issues with drawing bitmaps if they are large enough, and I wasn't drawing individual pixels. On the other hand, I was drawing potentially a couple hundred of them. If you find the performance to be inadequate, you might want to consider something like MonoGame.
Another point, if you are drawing a game map, is that pixels wouldn't be all that important, only vertices would be important. You'd be drawing lines between the vertices.
Drawing individual pixels are neccessary for creating the hexagonal bitmap in the first place - I don't like any of the drawingprograms I've found. For actually running the game, I'd be rendering bitmaps. Quick draft: maybe 13x13 hexes x {floor + wall + monster + treasure} ~= 1000 bitmaps of size 32x32. I'm aiming for turnbased, so 1000ms is liveable, although off curse less is preferable.
As a Visual Beginner*: GDI is the default gfx parts of VB, and MonoGame is a faster** "addon"?
(Beginner*: I know QBasic; my main reason for dabbling in VB instead C# or pascal)
(faster** and many other things, faster being relevant here)
(PG: culture-clash: I've never seen anything censored by PG that I wouldn't have said in school - even some teacher would say [look at first post]. It's kinda hard to tell when one is on a USA-site when it ends in .com not .us.)
If you're most familar with QBasic, then perhaps exploring QB64 would be of interest.
I've run some graphical QBasic programs in QB64, but the only problem is that they can run much too fast in QB64.
Of course, QB64 has added a lot of extensions to the language so support much more complex graphical capability, such as 3D with OpenGL.
Not as convenient though, since you have to write the code and then it gets converted to C++ and compiles to an executable. Not a simple integrated IDE where you can step through the source code interactively.
"Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930
(PG: culture-clash: I've never seen anything censored by PG that I wouldn't have said in school - even some teacher would say [look at first post]. It's kinda hard to tell when one is on a USA-site when it ends in .com not .us.)
Yeah. Some people think I don't swear. They don't know me. Still, this site is pretty narrow, in that regard. I'm a biologist, which is really a study of sex and eating, with a bit of habitat added at times. I don't even know whether or not that last sentence will get past the censor. Such is life.
You're right in what you are saying: GDI is the built in graphics tool. It will take you a long ways, but it is primarily CPU based. To go beyond that, you need something that will take advantage of the GPU on your graphics card. MonoGame is one of a variety of options in that regard. Also, they are all somewhat more difficult to learn and use than GDI...plus, it uses C#, though you can use it in VB. Basically, if GDI gets you all you want, then stick with it. If it doesn't get you all the performance you want, then MonoGame is probably the direction to go.
Drawing individual pixels are neccessary for creating the hexagonal bitmap in the first place...
No, if you want to produce some output like this (antialiased rendering of a 13x13 HexTiles-Grid):
...then there's no need to set individual Pixels (especially not, when you want anti-aliased edges on your hexagons).
Originally Posted by Andrew0Red
As a Visual Beginner*: GDI is the default gfx parts of VB, and MonoGame is a faster** "addon"?
GDI might be the default-rendering-lib underneath most Forms on a Windows-OS,
but you can use (or switch to) different GUI-libs at any time.
The above for example, was produced with VB6...
(using a COM-wrapper for the Cairo-Vector-lib, all in about 15 lines of code or so).
The example currently runs "timer-triggered" with about 25 FPS, causing a CPU-load of 1-2%.
I was only applying a 2Pixel-wide "stroking" on all these Hexagon-Paths currently,
but a "path-fill" (with different solid colors, but also from pre-loaded "bitmap-brushes") could be done as well of course.
HTH
Olaf
Last edited by Schmidt; Nov 16th, 2020 at 01:35 PM.
Ha meister Schmidt, you've just taken the wind out of my sails! Never mind, this is the VB.Net forum, so I suppose there is some point in posting my own idea of how to paint a grid of hexagons and to time them for performance. No external packages are needed. It's all done with GDI+.
My approach is to generate the hexagon vertices geometrically. Then they can be used for drawing, filling (with clipped image) and hit-testing of individual hexagons. As for performance, I get 4 milliseconds to draw 13 x 13 empty hexagons, and a total of 15 milliseconds or so to paint them all with randomly selected images. Obviously the timing depends on the hardware to some extent.
I start with a method for reading images from files -- mostly photos, because I have a lot of them -- and condensing them to 32 x 32 thumbnails. That's the only slow part, because shrinking an image from 12 megapixels to 1024 pixels takes a while. I presume that's only needed during development, because the thumbnails can be stored as Resources or as files for use at game time. For the moment, I've stored them in a List(Of Bitmap). Selecting from the list seems practically instantaneous, because the timing is the same regardless of how long the list of images is (10 - 1,500 tested).
I guess I'd do bmp.setpixel(15,47,swankyColor), then PictureBox1.Image = bmp everytime?
Originally Posted by .paul.
Loop through the pixels. Set your PictureBox image last
Well, technically you don't have to keep setting the picturebox image to your bitmap.
Once you've assigned the bitmap to the picturebox, you can just update the bitmap and then refresh or invalidate the picturebox to have it update the screen with the current state of the shared bitmap object.
Quick example of drawing "dots", i.e. setting pixels in a bitmap, using SetPixel.
Add a Picturebox to a new project, and add the following code. Drag the mouse on the picturebox. It will update the bitmap, and then reflect the change to the screen when it has a spare amount of event processing time.
Code:
Public Class Form1
Dim drawSurface As Bitmap
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
drawSurface = New Bitmap(PictureBox1.ClientSize.Width, PictureBox1.ClientSize.Height)
PictureBox1.Image = drawSurface
End Sub
Private Sub PictureBox1_MouseMove(sender As Object, e As MouseEventArgs) Handles PictureBox1.MouseMove
If e.Button = MouseButtons.Left Then
drawSurface.SetPixel(e.X, e.Y, Color.Black)
PictureBox1.Invalidate()
End If
End Sub
End Class
p.s. No guards in place in this example, so don't drag the mouse outside the bounds of the picturebox. You can't set pixels outside the bounds of the bitmap. If you were drawing the dots, rather than setting the pixels, then drawing outside the bounds would just be clipped, not an error, so more convenient.
p.p.s. Added a bounds guard for SetPixel
Code:
Public Class Form1
Dim drawSurface As Bitmap
Dim drawBounds As RectangleF
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
drawSurface = New Bitmap(PictureBox1.ClientSize.Width, PictureBox1.ClientSize.Height)
PictureBox1.Image = drawSurface
drawBounds = drawSurface.GetBounds(GraphicsUnit.Pixel)
End Sub
Private Sub PictureBox1_MouseMove(sender As Object, e As MouseEventArgs) Handles PictureBox1.MouseMove
If e.Button = MouseButtons.Left Then
If drawBounds.Contains(e.Location) Then
drawSurface.SetPixel(e.X, e.Y, Color.Black)
PictureBox1.Invalidate()
End If
End If
End Sub
End Class
Last edited by passel; Nov 17th, 2020 at 08:56 AM.
"Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930