don't you need to loop thru each segment? and don't you need to have some delay to give your eye a chance to register it.
when you change a display value you want to determine what segments need to be on when in some array(s) that blindingly update the display in a background loop without needing to do any more higher level processing
and i guess you've figured this out, by driving each digit, each segment pin only needs to drive a single segment at a time, there may be 7 segments on at a time
Yes. The delay also requires the LED/seg to be turned off or the "opposite corner" of the matrix (assuming pins are used to make active cathodes and anodes) would also light.
The For loop goes though all of the digits. For each one it determines whether the current segment is supposed to be on or not, and sets the corresponding common anode or cathode state for that digit. Things then stay that way until the next refresh, which in my case took place every other milli(), or 2ms, at which point you move on to the next segment.
I had all that code in loop() with a test to see if millis() had changed. But if I were doing it today, I would combine the refresh with the millis() interrupt, so all the refresh would be completely in the background. But the loop() still has to manage what's supposed to be displayed.
That's right. So the load on the segment driver depends on how many digits there are. If you have two digits, or four, a GPIO can probably handle that at something like 5mA per segment. That's probably enough for modern high-efficiency LEDs even though each segment is only on 1/7 of the time. But beyond that it becomes dubious, and you need some kind of driver. The common pin, however, never sees more than one segment's current at a time. So if you have enough pins to spare, those can be driven by GPIOs directly, with a resistor.
So one advantage is that you may not need as many resistors. And the on-time will always be 1/7 no matter how many digits there are. And depending on how bright it needs to be, and how efficient the LEDs are, it may be possible to do four digits without having to use any transistors.
If doing the traditional multiplex by digit, your common pin always has to be able to sink or source 7 segment currents (for an "8"), even if there's only one digit. That usually requires a transistor on each common pin. And the on-time will depend on how many digits there are.
So they each have advantages and disadvantages, and you just have to pick what's best for a given situation. I think the Arduino 7-segment library supports both.
But for 12 digits, it's going to be complicated powering everything no matter how you multiplex it, if you multiplex at all.
8 segments (for an "8+DP")
Years ago I used the circuits Grumpy_Mike posted in post #6. Mostly common cathode 7 segment displays. I did use a BCD to 7 segment decoder chip(s). We called it "strobing" and it happens so fast you never see flicker or similar. I would use common cathode displays and 2N3904 transistors to turn the displays On and Off. Using a BCD to 7 segment decoder reduces your pins needed count. The strobing of displays goes back to the early 80s long before the stuff we have today.
I also liked the kolaha suggestion inpost #3 where it looks like the above but all in a single package.
Those would be my suggestions and check your displays as to the max current for example when you display a number 8 using all 7 segments.
Ron
another hardware option are these 7 segment display i thin i2c modules.
As I said before:-
So any code posted so far is useless unless we know what you have.
I also note that after your initial post you have not made one single reply to any of the contributors. Unless you cooperate with us we have absoloutly no chance of solving your problem.
No you have not!
You show a Arduino Nano in your physical layout diagram when in fact you have a Arduino MEGA2560? This only serves to confuse people at best. And does not reflect, in any way, what you have wired up to what.
So have you gone away?
Are you confused by the questions you have got so far?
Hi,
I don't think there is much else we can do until @adrish2012realiam replies to our basic requests.
Tom... 
i think adrish has explained the gist of what he's trying to do.
considering this is his/her 1st post, there is no doubt some confusion in explaining things, understanding why some details are important and others aren't
besides the code to display the digits, it's not clear what else the code is expected to do.
hopefully @adrish2012realiam will understand and provide more details
If that's a TM1637-driven display, the brain chip can drive six seven-segment displays so only two would be needed.
It's an I2C-like protocol and the IDE library manager has several options to choose from.
Still at it then?
He has not specified if he has a common anode or common cathode 7 segment display. So everything else you have posted is just bunkum until we know. Including comments such as:-
you seem to have chip on your shoulder.
the code i posted is fine regardless of common anode/cathode. it's easy enough to invert the hex values. for example that code includes a separate segment map if the display were upside down
the comment about delay was for Sherman who said it wasn't so difficult.
the code i posted is actually better suited for individual segment pins using the loop instead of shiftOut()
i think it would be helpful to just try to explain things and help him figure out what the right questions are
Not a chip but you. You know all about what that is because I sent you a private message, which you have seemed to have ignored. You have a habit of sending misinformation that confuses beginners into deserting the forum, due to the arguments you keep having with me.
So what happens if he ever tries the code? A 50% chance of working at best.
I remind you the purpose of this forum is to solve users problems not post confusing misinformation. Just keep it simple.
Let's see if this poster ever comes back, or like the others is gone for good somewhere else.
But, I have observed that some veteran Forum Members insist to offer "hints to the solution" of the problem instead of spoon feeding. What is your opnion?
Let me correct this. Its 0%. Even the prefectest code of the universe is junk without the hardware it is designed for. We do not have any for a "12 digit shift register multiplex"-thingy in this thread.
Yes. In my opinion the aim of this forum is to help people learn. We are not a pack of code monkeys willing to write code on request. As post#5 illustrated.
But that does not mean that the hints just stop at being hints if the OP asks the correct questions. Like "the bit I don't get is where xxx happens" Then you can add further information and maybe later the odd snippet of code to help.
Some members might want to write something similar in an emulator, but there is always the danger of the emulators working on idealised components. For example most emulators will happily work without I2C pull up resistors, where as in practice this will often cause problems.
I quite agree, I just couldn't be bothered going trough the code to check. Especially when I have done this on other occasions with the same individual and found it to be rubbish.
Of course, the codes are rubbish when they are seen from your expertise level. Otherwise, those are the results of the efforts of a novice.
the purpose of posting the code was for the OP to look it over and understand what the code needs to do. It's not intended to be the solution and the OP goes away without learning anything
i think many OPs simply want to know "how" to do what they think they want. Clearly describing "what" the code needs to do is much more difficult than "how" it can do that.
Helping OPs learn to describe "what" they want also needs to be supported. their description needs to be complete, correct and unambiguos.
one approach is to give them code based on what they said but doesn't solve their really problem. Presumably they can see how it matches what they said and thatyhelps them better understand that they need to be clearer.
no doubt i use all the features of C. i believe i often present OPs with simpler solutions than what they may present not using those features and they see how those features work
some are willing to spend the time to understand what is presented. Others apparently want to be spoon fed. I think the "dumbed" down approaches by not using arrays, or using arrays but not structs, or avoiding the use of pointers just makes the code more difficult to understand
i don't think this is encouraging (esprecially in bold)
A quick reminder to keep the discussion about helping the OP, the stuff about who is worthy of help or how best to help is well covered in topics elsewhere on those and similar topics.
and then there are those who flog what ai spits out without checking....