Directory support for object inclusion
Brett Weir
Posts: 288
There really needs to be support for directories with Spin object inclusion. I have a lot of applications that use a lot of spin files that are generated by tools, for things like graphics, music, etc.
In any other language, this would be very manageable. Code could be nicely organized, and projects could refer to a common repository of assets no problem.
But because OBJ definitions don't support paths at all, every project basically looks like this.
Which becomes quite unmanageable; any game that uses, say, bullet.png, has to have its own copy of gfx_bullet.spin, and must be regenerated in every project every time that graphic changes. It's not maintainable at all.
The lack of this feature makes automated content generation tools difficult to use effectively, makes projects difficult to organize, makes code sharing or common media folders impossible, and holds back the language in general.
Does anyone else find this to be a major handicap for project management?
In any other language, this would be very manageable. Code could be nicely organized, and projects could refer to a common repository of assets no problem.
.
├── gfx
│ ├── effects
│ │ ├── boom.png
│ │ ├── gfx_boom.spin
│ │ ├── gfx_pixmain.spin
│ │ ├── gfx_starmap.spin
│ │ ├── pixmain.png
│ │ └── starmap.png
│ ├── enemies
│ │ ├── gfx_ibot.spin
│ │ ├── gfx_idrone.spin
│ │ ├── gfx_macrosoth.spin
│ │ ├── gfx_tank.spin
│ │ ├── ibot.png
│ │ ├── idrone.png
│ │ ├── macrosoth.png
│ │ └── tank.png
│ ├── fonts
│ │ ├── chars_cropped.png
│ │ └── gfx_chars_cropped.spin
│ ├── player
│ │ ├── gfx_head.spin
│ │ ├── gfx_healthbar.spin
│ │ ├── gfx_player_small.spin
│ │ ├── head.png
│ │ ├── healthbar.png
│ │ ├── player.png
│ │ └── player_small.png
│ ├── tilesets
│ │ ├── gfx_tiles_pixel.spin
│ │ ├── tiles_pixel_collision.png
│ │ └── tiles_pixel.png
│ └── weapons
│ ├── bullet.png
│ ├── gfx_bullet.spin
│ ├── gfx_laser.spin
│ └── laser.png
├── maps
│ └── map_pixel.tmx
├── music
│ └── pixel_theme.song
├── piXel.spin
└── proj
├── piXel.binary
├── piXel.side
└── tags
But because OBJ definitions don't support paths at all, every project basically looks like this.
boom.png bullet.png chars_cropped.png gfx_boom.spin gfx_bullet.spin gfx_chars_cropped.spin gfx_head.spin gfx_healthbar.spin gfx_ibot.spin gfx_idrone.spin gfx_laser.spin gfx_macrosoth.spin gfx_pixmain.spin gfx_player_small.spin gfx_starmap.spin gfx_tank.spin gfx_tiles_pixel.spin head.png healthbar.png ibot.png idrone.png laser.png macrosoth.png map_pixel.tmx piXel.binary piXel.side piXel.spin pixel_theme.song pixmain.png player.png player_small.png starmap.png tags tank.png tiles_pixel_collision.png tiles_pixel.png
Which becomes quite unmanageable; any game that uses, say, bullet.png, has to have its own copy of gfx_bullet.spin, and must be regenerated in every project every time that graphic changes. It's not maintainable at all.
The lack of this feature makes automated content generation tools difficult to use effectively, makes projects difficult to organize, makes code sharing or common media folders impossible, and holds back the language in general.
Does anyone else find this to be a major handicap for project management?
Comments
-Phil
That's good to know. So I'm not the only one.
This issue makes any kind of shared graphics repository impossible. What is the technical limitation preventing this from being supported?
You need another editor however.
```
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Oct 21 2013
Compiling...
piXel.spin
piXel.spin(70:30) : error : Invalid filename character
Line:
gfx_boom : "images/gfx_boom"
Offending Item: /
```
I did see that you could add directories to the include path, and was able to, but that isn't quite what I had in mind. Is that what you're referring to?
To do what you (and I) want to be able to do would require modifying the OBJ syntax to include the file paths. I do not believe this has been done yet in OpenSpin. There has been discussion off and on about whether the paths should be absolute or relative, wheter the syntax should be OS-agnostic (math::simple_numbers) or not (Math\Simple__numbers), etc.
But, overall, it's a small sticking point in what really is a nice language and compiler. The key is just to be careful how you name your objects. I have thousands in one directory and, though inconvenient, it seldom gives me any real trouble.
-Phil