al_draw_prim can only draw 2GB models

[allefant]

I know, I know, al_draw_prim is probably not the best choice when dealing with large 3D models, but nowadays 3D models can easily be a few GB worth of vertices and I still get 60 FPS drawing them with VBO) :o

However a call like
al_draw_prim(v, NULL, NULL, 3000000000, 3500000000, ALLEGRO_PRIM_TRIANGLE_LIST)
will immediately crash because the "int" type makes it
al_draw_prim(v, NULL, NULL, -1294967296, -794967296, ALLEGRO_PRIM_TRIANGLE_LIST).

I'll try and create a patch to change all vertex indices to int64_t instead of int, not sure if that is acceptable for compatibility though.

[pedro-w]

Not sure if that'll work - at least one code path ends up in glDrawArrays which takes a GLint param for the start (docs) (I assume GLint is not 64-bit, maybe it is?)

allegro5/addons/primitives/prim_opengl.c

Lines 413 to 416 in 0be7a02

	static int draw_prim_raw(ALLEGRO_BITMAP* target, ALLEGRO_BITMAP* texture,
	ALLEGRO_VERTEX_BUFFER* vertex_buffer,
	const void* vtx, const ALLEGRO_VERTEX_DECL* decl,
	int start, int end, int type)

[SiegeLord]

This can't be changed for compatibility, but since I did want to add new ways of drawing primitives as part of #1003 , perhaps we can add the 64 bit indices for that API? That said, are you sure OpenGL supports this? Maybe Vulkan does?

[allefant]

Taking a closer look my problem wasn't actually the number of vertices but just the buffer size, which was easy to fix. I only have around 100 million vertices, but since each one takes 36 bytes that still was 3.6 GB, more than could fit in a (linux-gcc-32-bit) int.

[ReiquelApplegate]

What should the 64-bit function we're adding be called? al_draw_lprim for large/long?