You need a +1 on this for cases where cur spans just over grid lines. Simple example, let's say lstep is 40 (what it is on my setup), xmin is 30 and xmax is 90. xmax-xmin is 60. 60/40 turns into 1. But grid lines are drawn at 40 and 80 because xmin starts at 30.

Few things here. I think you need to cast the ((v2d->cur.xmax) / lstep) to integers. I'm getting assert below at immBeginAtMost with vertex_count of 149. Other thing is that you can't just use "cur.xmax". If you put axis close to right of screen then xmax is close to 0, which will give you almost no vertexes. Try it and it'll assert because you go past vertex count. You probably want difference of xmax and xmin. Using totlevels is ok but it gives you way more verts then needed because verts needed for other levels is reduced. Actually it skips verts on first levels if they are on next level so you may not even need to multiply by totlevels, you'll have to test.

Can remove these, cur_xmin_positive and cur_ymin_positive

for (int level = 0 ...

Delete declaration of level earlier this function.

C99 style thing -- can declare these below, first time they're used:

int i = (int)(v2d ...
float start = i * lstep;

Using immSkipAttrib means you can't setup color ahead of time here, have to remove this line and line 1520 to stop asserts.

Need to increment "i" here if cur.xmin is positive before using it to set "start". Simple example again, converting a float to int throws away the decimal, so 1.5 becomes 1, and -1.5 becomes -1. This shows that converting to int will always round towards 0. This is fine for negative cur because it rounds up, but if cur is positive it will round down and you will be drawing the first grid line outside the cur rect.

Same here, need to increment "i" if ymin > 0

Not sure why drawing X and Y axis is inside the levels loop. Doesn't this just draw them repeatedly for no reason? It was inside the loop in the old code too, strange. Maybe I miss something.

Empty (code) line between these 2 (GL) lines, for clarity.