let’s say… i wanted to draw 1000 lasers on the screen…
each laser in it’s own layer, each one fading away on it’s own time…
would you draw them using a single Graphics class and make 1000 lineTo() calls, or use a single bitmap and draw it 1000 times?
i just want to know which method is the way to go, in general… because i have no clue what’s going on low level nor what GPUs are optimized for.
I would try one h2d.Graphics object and let it draw all lines that you need. But to really know the answer you maybe need to check both methods/ways (e.g. with 10k lines) or also ask on discord. Usually (ppl like Yanrishatum and others) have a more profound understanding/“clue what’s going on low level” / “what GPUs are optimized for”.
an yeah, the discord, that’s wayyy better, thanks!
coming back to this…
because of my object-oriented design (and i’m now starting to understand how OO can go wrong…), i created an instance of Entity, which itself has an instance of Graphics, meaning: 1000 instances of Entity, Object, and Graphics, each. LOL. Is this a terrible idea? Or should i try to consolidate all of the drawing to a single Graphics object, separating the drawing part from Entity? I just want to know for like, *good design practices*. (the down-side of this is that i’d lose the ability to layer graphics tho… unless i create yet another layer helping class to order Graphics drawing…? 
)
another puzzle: i personally don’t know when/how Graphics is actually drawn. Like, iirc in MonoGame, you have a main draw function, and you just gotta draw everything in there, ordered, front-to-back (
maybe Scene/Layers handles everything for us 
…). For sprites in Heaps it’s the same as MG: SpriteBatch.draw (i think). But for Graphics, you just use the Flash API (lineTo, moveTo, beginFill, endFill, etc.), and it’s all auto-magically drawn! iirc, there’s no actual draw call needed from me.
basically, i’m just worried i’m doing 1000 draw calls, lol. I’m not too worried about 3000 class instances… or should i be? …
In terms of “good design practices” one would always try to decouple visuals from logic (like e.g. MVC, MVVM). Because then you can make changes to one side without worrying about the other. However you don’t need that when you just want to succeed to make a game that just works.
About how graphics are drawn I hardly know myself… but it is back-to-front and besides all trouble with HeapsIO if it’s one thing it’s at least a graphics engine that gives you layers etc. and most things are rendered just by adding them (Bitmap, SpriteBatch etc.). Only h2d.Graphics needs a proper setLineStyle or setFill then draw then maybe clear (which requires re-setup the precedent)…
What ever you do keep it as simple as possible. Just create something that compiles. 
The abstract code issues are only a problem when it comes to maintenance and change in the long-term. I mean when you plan to add features later you will have to re-deal with your code, whatever that looks like. And about the performance I guess you have to implement your different approaches so you can in fact really compare them one to another. I remember it’s possible somehow to see the number of draw calls for that…??
…
I have a very weird feeling these days people should go back to learn C in class, instead of getting tangled up in OOP… 