Forum Replies Created
-
Posts
-
I’ve used this one for $32: http://www.sparkfun.com/products/8739
Not the greatest quality picture, but it’s 640×480 color.
The pixel shifting is about moving pixels within the buffer, not moving the buffer’s position on the screen. All these functions should work with the Video Experimenter (because that’s normal TVout capability).
Why do you want to move the position of the overlay buffer? Is it not in the right place?
Try adjusting these values in spec/video_properties.h:
#define _NTSC_LINE_STOP_VSYNC 3
#define _NTSC_LINE_DISPLAY 216tim, thanks for the image and the feedback. I’ve forwarded a link to this thread to the owner of Cool Components.
Have fun!tim,
I’m very disappointed to hear that. I provide only kits to Cool Components, and they use their own assembly service. Have you contacted Cool Components about this? I will also bring this to their attention.Every assembled board purchased on the nootropic design web site is soldered by me and tested before it is shipped.
I have adjusted the silly attachment quota settings, so you may be able to attach a picture now.
Thx for bringing this issue to my attention.
-Michael
nootropic design, LLCYeah, it totally works — what a cool game! Thanks so much for porting to Hackvision. Whenever you would like to call it “done”, I’d be happy to make a video and add it to the games page: http://nootropicdesign.com/hackvision/games.html
Great job!
Michael
nootropic designIf you are using the ordinary Serial library, then yes, you are going to have problems like that. You need to use the polling serial provided by the TVout library.
The variable ‘g’ is a reference to the Processing PGraphics object which performs the drawing in Processing.
How is the variable “l_mesh” declared? Is it declared as type Layer?
If so, then you need to cast it to the type L_PolyMesh:
((L_PolyMesh)l_mesh).drawPolygons();That is, you have to tell the compiler that your object is not only a Layer, but is specifically a L_PolyMesh object.
Alternatively, you can declare l_mesh as type L_PolyMesh. Hope that makes sense.
Yeah, the problem is that anything that relies on interrupts is going to be in conflict with all the video interrupts. The timing gets screwed up. During the vertical blanking interval (at the end of each frame) there is a period of time when interrupts are not firing, so you can do your I2C communication then. Create a function that sets a flag indicating that we are in VBI. Then register that function to be called at the beginning of VBI.
void setVBIFlag() {
inVBI = true;
}
In your sketch setup, register this function:
tv.set_vbi_hook(&setVBIFlag);
Now, in your sketch main loop you can communicate with the compass like this:
if (inVBI) {
// communicate with compass here
inVBI = false; // reset the flag so we only try to communicate once per frame
}
I hope that makes sense. The interrupt driven nature of TVout makes this tricky. I had to do this when I communicated with a Nunchuk with my Hackvision product. You may also run into memory constraints because the I2C library is very bloated memory-wise. I trimmed it down in the Hackvision Controllers library, so you can take a look at that:
http://nootropicdesign.com/hackvision/downloads/Controllers.zipGlad to hear that Image2Code runs on Linux. Like I had said in email before, I had simply used a work PC to do my bitmap work, and I use a Mac for all development. I had spent some time looking for a tool to do the work, but didn’t really find any.
Obviously this forum doesn’t get a lot of traffic. There are only a few hundred Hackvisions out there, so it’s just not a huge community…
Submitting new games does help get some attention though, so let me know when you’ve got a cool game and I’ll do all the work to publish!
I’m afraid that noLoop() only applies to the entire sketch and does not control individual layers. You can accomplish what you want by using a flag on the midi layer to indicate whether it should be drawn or not. When a midi signal is received, set the flag to true. In your draw() method, just check the flag. If false return. If true, it will draw and at the end of the draw() method, set it back to false. Make sense?
Correct, if you are using interrupts, that will definitely interfere with the timing of the video generation which depends on timer interrupts.
Yes, it looks like a timer conflict. The Digit Shield uses Timer 2 for the multiplexing of digits. If your DMX code doesn’t use Timer 1, I could show you how to change the Digit Shield library to use Timer 1 for the multiplexing.
I’m pretty sure the initialization would be this:
// TIMER1
// Disable the timer overflow interrupt
TIMSK1 &= ~(1 << TOIE1);
// Set timer1 to normal mode
TCCR1A &= ~((1 << WGM11) | (1 << WGM10));
TCCR1B &= ~((1 << WGM13) | (1 << WGM12));
// Disable compare match interrupt
TIMSK1 &= ~(1 << OCIE1A);
TIMSK1 &= ~(1 << OCIE1B);
// Prescalar is clock divided by 128
TCCR1B &= ~(1 << CS12);
TCCR1B &= ~(1 << CS11);
TCCR1B |= (1 << CS10);
// Start the counting at 0
TCNT1 = 0;
// Enable the timer2 overflow interrupt
TIMSK1 |= (1 << TOIE1);
and the overflow ISR is this:
ISR(TIMER1_OVF_vect) {
TCNT1 = 0;
for(int i=0;i
}
}
