Jump to content

LinkoVitch

Members
  • Content Count

    2,779
  • Joined

  • Last visited

  • Days Won

    14

LinkoVitch last won the day on October 21 2013

LinkoVitch had the most liked content!

Community Reputation

2,101 Excellent

1 Follower

About LinkoVitch

  • Rank
    River Patroller
  • Birthday 03/06/1976

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Mossley, UK
  • Interests
    Coding, Computers, gaming, whisky, beer

Recent Profile Visitors

15,632 profile views
  1. Which then complicates the silicon as it now needs to handle phrase and qphrase alignments, means an extra address line too, just so you can save a few bytes of RAM? doesn't seem like a worthwhile trade of. I'm no silicon engineer, but I am pretty sure that things that seem trivial or simple in code are not going to be as simple or trivial to implement in silicon, added complexity I would imagine leads to greater chance of bugs in the hardware, more transistors needed etc, and if you are close to budget not everything is possible.
  2. Yeah, *NIX OSes (with the exception of MacOS) are case sensitive. It's worth getting into and not being sloppy with such things. If you keep everything correctly cased, then no issues, worth a little faff to correct case on stuff you are working on, it's a one off thing that doesn't negatively affect anything.
  3. I use it as part of my GIT servers CI/CD integration process. When I push up changes to my Sound Engine code, it automatically uses that container to test the project builds without errors and if successful generates a release zip file for me. I only released the container (which is like a small linux build with compiled versions of the tools) because I figured it may be handy for others as it was going on the Docker public repo anyway. If you run it, you will be dropped in at a command prompt from which you have access to make, rmac and rln. docker run -it hisol/jagbuild This won't be terribly useful unless you mount your local path containing your source into the container, then you can use those tools to build your source and get access to the result. so something like docker run -it -v /home/myuser/jagsource:/source hisol/jagbuild which would mount the local directory /home/myuser/jagsource into the container at /source, essentially allowing the container to see the files on your machine in that path, from which you could then run the tools cd /source make <magical make build stuff happens> That is pretty much it. There are plenty of help files etc on dockers website to explain the various switches etc, (you should really put --rm in that command after -it, or you will gradually end up with a full drive of old container volumes ) This should work under windows, but YMMV as Docker under Windows is mostly made of fail and crashes.
  4. You have no idea if his reasons are good or not, he doesn't owe you anything. He is even leaving the repo up for a couple of days to allow people to make copies if they so wish, so he's not stopping you from doing anything. You are being very self centred. Hardly "taking his ball and going home", he has developed and provided support for this language for the last 6 years for FREE, and from what I have seen very little thanks! He is under no obligation to keep developing or supporting anything. If anyone could be accused of "taking their ball" etc, it would be you for this poor attitude.
  5. Assuming I am understanding what you are doing (I think you might have pasted the wrong bug link BTW) I think the current version or RMAC does work correctly for calculating the difference between two labels. I have the following code in the SE .pc: move PC, JUMPTO addq #(mainloop - .pc), JUMPTO to calc a branch to the main loop, and that is working fine for me.
  6. I'd have thought the CPLD would have been programmed via the JTAG and the voltage supplied by the programmer itself via the JTAG header? RE amps, it will draw what it needs, you just have to supply enough potential. IIRC the analogy is imagine the wire as a water pipe, Amps is the diameter of the pipe, voltage is the pressure, so as long as the "pressure" (volts) isn't too high the amps won't matter.
  7. I would suggest one of the tips that is flat and angled (looks a bit like a knife point). The theory I read was that the tip is cooler at the point than the larger portion, so as you drag along the pins keeping the whole flat edge on the pins with the point end being the last to touch the pin as you pass over, the solder is slightly cooled and it distributes evenly. Obviously dab a LOAD of flux over the unsoldered pins with the part in place, makes a cool popping noise as you solder but helps with the bridges. My drag soldering is a bit naff tho
  8. Yes the CLUT can only have 256 colours in it. Don't use an indexed bitmap object, use a 16bit or 32 bit object. The CLUT isn't used if the colour data is stored directly in the pixel data. Might be worth asking this question in the RB programming section, I have never used Raptor Basic
  9. Your assumption is wrong, the Jag can display 24bit true colour images, 16/15bit RGB, 16 bit CRY, as well as 256x 16bit colours on screen at the same time.
  10. I don't know why you are fixating on 16 colour TBH, that is just one of the options. Personally I'd go for 16bit 1st unless it was blatantly unnecessary, and scale back as issues arise. I'd not be surprised if the large static background on Rayman was 8bit, it has a fairly subdued colour scheme, possibly less than all 256 freeing up some of the palette for the text etc. I am speculating I've not tried pulling the ROM apart yet
  11. From my own CoJag digging, ATari do like to use 8bit colours.. dunno why, CoJag has more memory, more ROM, more CPU and more bandwidth..
  12. Think we are at cross purposes here and perhaps I haven't understood your meaning. 1) Yes obviously if you are taking a photo and want it to look like a photo, a horribly dithered mess isn't going to cut it. If you have an image that can be rendered using less than 256 distinct colours and look the part, then that should absolutely use indexed pixels. There maybe fewer colours, but they are still 16bit. 2) I am no artist :), so yes there are more ways to do things which won't mangle foreground sprites. Having a more subdued palette in the background works nicely for me (in games where I have seen it). If there is memory and bandwidth to spare, sure have a 16bit or a 32bit colour background.. but if the background isn't the key focus of the game, might be worth halving the memory/bandwidth footprint and squishing it into 256 or less. Won't always be possible. It's going to matter precisely on the project and the resources, there is no single right answer.
  13. Nope, I think you should re-read what I put about the reasons for using indexed objects. You are absolutely correct you should use indexed object for those types of images, and I never said otherwise. Save on storage, bandwidth etc, much more efficient. I *DID* say that you *COULD* use those and the jag would be able to handle it, counter to what you put saying it could not. I don't recommend you do mind, but if done properly the Jag COULD do that.
  14. I guess you refer to this Chris: And that "technique" was known way back in the days of them designing the silicon and publishing the developer manual. Technically EVERYONE has used that technique, because without it the OP crashes/acts weird, and probably pretty much everyone else with more than a handful of objects on the screen will have done it. This isn't some secret dark art that only the elite few know. I've actually mentioned it in passing a bunch of times in my posts on this thread in fact.
  15. I'm going to chip in as there seems to be some confusion with what I said and stuff, so just to add in my 2p Fishing frenzy most certainly shouldn't tax the jag at all, punting sprites it can do. Of course a badly created object list will overly tax the system for what it is drawing on the screen, but even with a simple list with no branches I'd imagine the jag could happily handle fishing Frenzy. There seems to be some confusion about the "bit" of colours... Now, this is the confusion.. a 1bit, 2bit, 4bit and 8bit image on the jag are all using 16bit colour :).. the 1,2,4, & 8 refer to the size of the colour index into the CLUT (Colour Look-Up Table). Each entry in the CLUT is 16bit RGB or CRY depending on mode. The index value of a pixel simply points to which colour in that LUT to use. So a 1bit image can be 0 or 1, 2bit = 0-3, 4bit = 0-15, and 8bit = 0 - 255. The assets are high quality colour, just the pixel data is stored efficiently. Plus backgrounds should be somewhat duller and less detailed to avoid making foreground objects difficult to differentiate. Not for the graphics, but depending on the complexity you can spam the bus by making too many calls or tie the OP up with too long a list (the whole list is processed every single scan-line, every frame.) If you have a large image using indexed pixels saves a load of RAM and also memory bandwidth. The OP will like to read it's data in 64bit wide chunks. 1 64bit read is 4x 16bit pixels, 8x 8 bit pixels, 16x 4 bit pixels, 32x 2 bit pixels, and 64 1bit pixels.. so for Jeffs 352 pixel @ 4bit that's 22 reads to read a whole scan-line, vs 176 reads if it were 16bit. (assuming my dodgy mental maths worked there ). Of course if the object is smaller than a single read, you are going to waist a chunk of that potential pixel slurping. Whilst this may all sound super ossum, it does have it's own cost, in that an indexed Object has to also do a lookup in the CLUT to find the actual colour to paint, so there is additional overhead there, only slight, but still something to bear in mind. oh and you are limited to 256 colours in total shared between all those Indexed objects. Sorry Jeff, it won't.. not if it's done correctly. When you move something on the screen with the OP, it doesn't actually "move" anything. If you badly build your list, don't make use of branches and a well structured list, or have overly large objects that hang off the sides of the screen, then yeah it's going to struggle and fail. But it is entirely possible to have a full screen image with many layers of parallax. Sorry if that's a bit all over the place HTH anyway
×
×
  • Create New...